
On 16/12/14 12:36, Johan Tibell wrote:
Hi!
On Tue, Dec 16, 2014 at 2:42 AM, Zach Moazeni
mailto:zach.moazeni@gmail.com> wrote: A concrete example: If I make backwards incompatible changes to a package whose latest version is 1.0.x, should the next version be 2.0.x or 1.1.x? What sorts of things should I consider for choosing 2.0 over 1.1 and vice versa?
Unless you really change the API drastically I recommend bumping the B component.
Another question, by far most packages I have encountered either lead with a 0 or a 1 for "A". Does that have some bearing on the long term stability that package users should expect in the future?
This is something that happens a lot in open source, in Haskell or elsewhere. We We programmers are afraid of calling something 1.0, because that somehow means "done", which we never (think we) are. :) Lots of really stable Haskell libraries (e.g. containers) are still on version 0.X.
Upper bounds contribute to this problem, too. Suppose you've decided that 'containers' is stable enough to be at 1.0. Now all packages need to be updated, because they most probably depend on 'containers < 1' or tighter. We saw something similar with text, people got angry. If a library becomes popular before it reaches 1.0, it probably never will. Roman