My opinion is that the version number shouldn't convey the idea of stability. It should be another field :)
In fact in Cabal there is a stability field:
https://www.haskell.org/cabal/users-guide/developing-packages.html#package-properties
But it's not very well specified/used.

Anyway the fact that we like to have "V1.0" to mean "work done" is more a question of aesthetic.
The version number carries three different informations IMO:
- tagging a specific state of the sources,
- give an order between the versions,
- give information about the level of changes.
The third one could be separated. It could be made into a field containing the level of changes, such as "minor changes"/"API breaking changes". Then the version tag could be made what you want, even tagging "V1.0" a minor change.
Just my 2 cent :)



On Tue, Dec 16, 2014 at 12:39 PM, Vincent Hanquez <tab@snarc.org> wrote:

On 16/12/2014 11:23, Roman Cheplyaka wrote:
So I need to wait till I have an API-breaking change in order to mark a
package as stable? That's... ironic.
 This is one of my issue with the PvP. with the PvP versioning you're not able to convey any other informations apart from the API "changing".

Which means you can't properly convey:

* major new features: by bumping the major, despite the API not changing
* security (by bumping the minor or patchlevel, regardless if the API change)
* the stability (bumping to 1.x).

Text is one of canonical example when it was bumped to 1.x recently and lots of people complained that it wasn't the right thing to do.

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.

 Indeed.

--
Vincent

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe