I have some concerns about the "a backwards-incompatible change should result in a new package" idea.
Firstly, it would clutter the package server. This would also confuse new users, who would arrive at the package server and see several editions of the same package. For just Cover we would have two packages already, and Cover is under a year old. Secondly, while I agree that compatibility is a primarily social question, our tooling should make answering that question easy, not cumbersome. Having to create a new package for something that is logically a modified version of an existing package seems cumbersome, for both the package maintainer and for the package user. Finally, a question, assuming we with stick with the creating new packages for incompatible changes. If one discovers that some part of their interface is a mistake, but that fixing/removing it would be backwards incompatible, is creating a new package still the correct decision? For example, in Cover's upcoming release we have split the repository into a two parts, partitioning the Coveralls support into a separate package. This is because we don't want to implicitly endorse Coveralls as a coverage front end, and because we would like to support several coverage front ends without making each user install all of them. Should we, for our next release, create a "cover2" and "cover-coveralls" package, leaving the package server with "cover", "cover2", and "cover-coveralls" packages? --Spencer On Tue, Sep 1, 2015 at 12:42 PM Jack Firth <[email protected]> wrote: > Personally I think it would also be helpful to encourage people to make > `unstable` collections for their packages so they know they have somewhere > to experiment with new features before committing to them fully. This is > the approach Alex and I have been using on our lens package and it's > working fairly well. > > -- > 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/cd4d21f8-63a9-4d62-86ae-1af8671cd4da%40googlegroups.com > <https://groups.google.com/d/msgid/racket-dev/cd4d21f8-63a9-4d62-86ae-1af8671cd4da%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAF4wvDziDkNjqhk2nj0uCJybKOzdYYrm0QDxnGhckoGAe4E%2BDg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
