Use Semver Standard 2.0.0 #90
Comments
There are also some nice ways to specify versions in https://docs.npmjs.com/misc/semver |
The goal is to remove humans from versioning because it can be done automatically. I understand that people like to put multiple meanings on versions (one about API changes and one about stability) but I'd like to separate those things. Longer term, you will be able to mark your packages as "unstable", "experimental", "stable", "unmaintained", "deprecated", etc. I think having these two data points conveys the information in a better way. The 0.* range gets rid of all of these benefits when you can actually know how APIs change. So this decision was made intentionally, and I hope I will be able to communicate the long term plan more clearly. |
That's cool. Somehow I missed the automatic versioning. Anyhow, I agree with what you say about 0.*, it was just an example, and a bad one. It's a bad one because it is still semver (or subset of), even if you enforce the 1.0.0 rule (which, actually, is a recommendation in the npm docs); if currently elm-package is enforcing semver (with restrictions, of course) - let's write it in the readme by its name. Something like "a subset of semver 2.0.0". I'm not saying this standard is holy or something, it's just easier to understand if you call it by its name. |
That makes sense! I think "subset of semver 2.0.0" is accurate, and I see how that's helpful for folks. |
As described in http://semver.org
Of course, part of the responsibility is given to the authors, but the current instructions are quite similar to the standard (but not the standard - for example, packages start from 1.0.0)
The text was updated successfully, but these errors were encountered: