This repository has been archived by the owner. It is now read-only.

Use Semver Standard 2.0.0 #90

Closed
iamdoron opened this Issue Jan 11, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@iamdoron

iamdoron commented Jan 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)

@iamdoron

This comment has been minimized.

Show comment
Hide comment
@iamdoron

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

@evancz

This comment has been minimized.

Show comment
Hide comment
@evancz

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.

Contributor

evancz commented Jan 11, 2015

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 evancz closed this Jan 11, 2015

@iamdoron

This comment has been minimized.

Show comment
Hide comment
@iamdoron

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.

@evancz

This comment has been minimized.

Show comment
Hide comment
@evancz

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.

Contributor

evancz commented Jan 11, 2015

That makes sense! I think "subset of semver 2.0.0" is accurate, and I see how that's helpful for folks.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.