@notjack (in response to you side channel msg “it does have tradeoffs - maintaining constant backwards compatibility is both extraordinarily difficult and quite limiting. There’s interest in exploring alternatives for racket.”) Jill, why doesn’t the Racket community explore a form of function annotation whereby exported function have a lifecycle in that the start out as raw (only the library writer uses/develops it at this stage, thenmove onto draft - this stage maybe one consumer might use it, but both raw and draft are susceptible to change, anyone using it knows this is shifty sand. Once happy the library writer puts a stable annotation, signalling this function signature will not change. Only newly named function exports may be used should it be required. After stable the deprecated annotation is used, the function implementation still exists but an evaluation warning is printed. After this the legacy annotation is used, here the entire function implementation is replaced by an assert. This gives the pkg implementor flexibility to evolve the exported function against a wider user base. 2cw

@samth thank you! )

@setori88 Although I don’t think I’ve seen it formally documented (?), there is a convention about not using things a package provides under a private module path. A related signal is that if a package doesn’t document something yet/ever, maybe I shouldn’t use it. IMHO these are fine, existing ways to handle the “raw” and “draft” stages you mention. (Also, it’s wonderful to share code on GitHub or wherever, even if you’re not yet willing/able to commit making it a package for other people to depend on.)

As for “deprecated”, I think that’s something to signal through documentation. (Not a code warning, because next point…) As for “legacy” a.k.a. 410 Gone, I think the answer is “please just don’t do that; why would you do that to users of your package.”

I’ve seen @jeapostrophe point out that package ecosystems are as much social as technical.

> package ecosystems are as much social as technical The old Perl community is an excellent example of this.

And JavaScript / npm is a good example of the prevailing alternative.