Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upUse Semver Standard 2.0.0 #90
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
iamdoron
Jan 11, 2015
There are also some nice ways to specify versions in https://docs.npmjs.com/misc/semver
iamdoron
commented
Jan 11, 2015
|
There are also some nice ways to specify versions in https://docs.npmjs.com/misc/semver |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
evancz
Jan 11, 2015
Contributor
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.
|
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. |
evancz
closed this
Jan 11, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
iamdoron
Jan 11, 2015
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.
iamdoron
commented
Jan 11, 2015
|
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. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
evancz
Jan 11, 2015
Contributor
That makes sense! I think "subset of semver 2.0.0" is accurate, and I see how that's helpful for folks.
|
That makes sense! I think "subset of semver 2.0.0" is accurate, and I see how that's helpful for folks. |
iamdoron commentedJan 11, 2015
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)