On Mon, Aug 31, 2015 at 10:35 AM, Jay McCarthy <[email protected]> wrote: > I wouldn't say there is or has been a policy. There's advice based on > what the release process packages do. > > Generally, adding a new export or module is not considered > incompatibility. (Although technically it is, because it could reduce > the set of other packages that can be simultaneously installed.) > Indeed, the question is not one of extent, but of intent.
*Any* semantically-visible change, including the most trivial bug fix, will by definition break some potential client. e.g. a client that would expect the buggy case to be a bug, or the set of working cases to be exhaustively covered by some inductive definition (e.g. type-checker), etc. Adding a working case will break those clients, those types, etc. The question is one of intent. Are the intended clients going to keep working and/or be updated to keep working with the current library, or are you making such changes that they will break and won't want to adapt to the modified API? > Once you've committed to compatibility (by labeling a package with > version "1.0"), then any incompatible change should end up in a new > package/module, because at that point there's really no meaningful > connection between the old code and the new code, except maybe similar > purpose. > My experience with ASDF taught me that "compatibility" is not a social notion, not a strictly technical one. See my ASDF3 article: http://fare.tunes.org/files/asdf3/asdf3-2014.html#%28part._backward_compat%29 —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Be yourself, everybody else is taken. — Oscar Wilde -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAN7nBXcjYqGRJYiQ7GqiO40SmEa__s4GPcjrh2Qb0sV2KvXjvw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
