mirror of
https://github.com/semver/semver.git
synced 2026-07-11 05:12:48 -05:00
Can we have a consistent version number for Semantic Versioning? #198
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#198
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @HansOlsson on GitHub (Sep 16, 2015).
Due to another ticker I realized that the following two:
http://semver.org/
https://github.com/mojombo/semver/blob/master/semver.md
are both publicly available versions called "Semantic Versioning 2.0.0"- with slightly different contents (i.e. the latter is a "patched" version - removing an ambiguity and some minor spelling errors - similarly as one would release a new patch version to initialize a local variable).
Having two different versions of Semantic Versioning 2.0.0 with the same name and version makes it difficult to discuss which version of Semantic Versioning we are using.
The confusion is even more ironic considering that one of the changes was caused by a discussion about nightly builds, https://github.com/mojombo/semver/issues/200 , - and one could argue that https://github.com/mojombo/semver/blob/master/semver.md is a nightly build.
The logical solution would be rename the latter version to "Semantic Versioning 2.0.1", "Semantic Versioning 2.0.1-Beta", "Semantic Versioning 2.0.1-Nightly-2015-09-16", "Semantic Versioning 2.0.1-Nightly.2015.9.16", or something similar
@HansOlsson commented on GitHub (Sep 18, 2015):
Note:
This ticket is just about making it convenient to refer to the different versions (and leading by example).
The change is not formally required (as far as I can see), since Semantic Versioning does not state that its versions confirm to Semantic Versioning.
@jwdonahue commented on GitHub (Dec 8, 2017):
@HansOlsson, the semver.org site has the standard. There are probably dozens of exact copies and modified versions all over the net that we can do nothing about, but I do agree that mojombo/semver, now semver/semver, should either have an updated version in the title or it should just have a place holder until someone decides on what the next release version is and that new version would only be reflected on semver.org site.
@steveklabnik commented on GitHub (Feb 11, 2019):
I believe this ticket was filed when the website was very different, as far as I can tell, this has been fixed. (And additionally would have been a good issue for the website repo, rather than this one.) Thank you!
@HansOlsson commented on GitHub (Jun 4, 2019):
It is not fixed:
https://semver.org/#spec-item-10 says
"Build metadata SHOULD be ignored when determining version precedence."
https://github.com/semver/semver/blob/master/semver.md says
"Build metadata MUST be ignored when determining version precedence."
@klehelley commented on GitHub (Jun 4, 2019):
I haven't made a complete diff of the content on the website and the content of the
v2.0.0tag of thesemver/semverproject, but for your specific example I see no difference.The version of the specification that can be found in
master, that you are using to point out differences, is just a work in progress and not a final version; thus it should not be considered authoritative.A new version of SemVer will eventually be released, considering some of the changes being discussed around here, though it will likely take time. That new version should include the change you are pointing out.
@HansOlsson commented on GitHub (Jun 14, 2019):
The problem is that we cannot see this from the page itself - which says "2.0.0" not "3.0.0-Development"; and we are led to this main page by link.
Having a development version visible on GitHub is common for many projects - and it seems that the conclusion is that there is no need to update their version number until released.