Re: [Haskell-cafe] Why does Haskell PVP have two values for the major version? "A.B..." and a couple other questions

On 16/12/14 13:00, Erik Hesselink wrote:

On Tue, Dec 16, 2014 at 11:49 AM, Roman Cheplyaka wrote:

...

On 16/12/14 12:36, Johan Tibell wrote:

...

On Tue, Dec 16, 2014 at 2:42 AM, Zach Moazeni mailto:zach.moazeni@gmail.com> wrote: 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.

I don't understand this. How is bumping 'A' different from bumping 'B'? You could just bump 'A' (to 1, for example) instead of 'B' when you make an API breaking change, and it's no extra effort for people who depend on you.

So I need to wait till I have an API-breaking change in order to mark a package as stable? That's... ironic. Also, if the library is stable enough, people would constraint the A version (e.g. 'containers < 1'), asserting that their package will probably continue to build even under minor API-breaking changes which are typical for stable packages. Now, by bumping my A version for a minor breaking change, I'm acting exactly against their intention, saying "hey, this is a massive change, you'd better pay attention before using it". That's not what an actual stable package is supposed to do. Roman