mirror of
https://github.com/semver/semver.git
synced 2026-03-10 07:52:20 -05:00
Dots in pre-release versions ("-rc.1") #21
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/semver#21
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 @hishamhm on GitHub (May 25, 2012).
The only part of SemVer that evidently clashes with the common "responsible" practice of program versioning is requiring dots between tokens of the pre-release part. I see this has been added between spec version 1.0.0 and 2.0.0-rc.1 -- I claim this is unnecessary and will harm adoption of SemVer.
I am the maintainer of LuaRocks and I have a sorting algorithm implemented for package versions that respects basically the same ordering as that proposed by SemVer, except I don't require the dots. This can be done by considering sequences of numbers [0-9] and alphabetic characters [A-Za-z] as separate tokens, ignoring any further dots and dashes. So, "1.9.3-alpha2-rc3" parses as "1", "9", "3", "alpha", "2", "rc", "3".
An RFC-style document has greater chances of becoming an accepted standard if it closely matches common practice. You see lots and lots of "2.0.0-rc1" out there; there's no technical reason to require that extra dot.
@rstacruz commented on GitHub (Jun 15, 2012):
I think one issue here is with hex numbers. What about
+build.da8e230? With your algorithm, that will be sorted asbuildda+8+e..., which may not be what you want....not that I think it matters, I think
rc1andpre3are use cases that are much more common.@JohnPeacock commented on GitHub (Jun 16, 2012):
I was just coming here to discuss this very topic and see that someone has already started it! I am also very interested in this topic (see the Perl version library for evidence) and I also see the mandatory periods as a handicap. Specifically, the 2.0.0-rc.1 specification doesn't include RPM's own rpmvercmp; love it or hate it, RPM is the most widely used structured version comparison out there, so it would be good to at least try and accommodate it if at all possible:
http://fedoraproject.org/wiki/Archive:Tools/RPM/VersionComparison
I think it is possible for Semantic Versioning to be a superset of the existing rpmvercmp code.
Like hishamhm, I think the periods should be optional (but recommended), but unlike him (and to touch on rstacruz comment) I don't think they should be ignored for parsing purposes. In other words, explicitly split the string on periods and hyphens and implicitly split on maximal alpha and numeric sequences. Additionally, it should be possible to permit the last element to be a hex number (the regex is quite simple). Thus rstacruz's example
+build.da8e230becomes "+", "build", da8e230.@hishamhm commented on GitHub (Jun 16, 2012):
That wiki page has a sign on top that says "This page is outdated and is only retained for historical reference".
I don't know how valid that page still is, but I think the spec listed there is a bit too free-form (in particular, I don't think semver should allow undefined results).
On hex numbers -- well, since we're talking semantic versioning, here's a semantic question: can a build snapshot really be considered a "version number"? I don't think build snapshots fit the bill, for four reasons:
@rstacruz commented on GitHub (Jun 17, 2012):
@hisham, I don't think it matters to sort hex numbers, they're most likely hashes like you said. However, in the counter-example I provided, the alphabetical parts "bled" through to the other string (making "build" become "buildda"), which is probably unwanted behavior. This was all I was trying to point out.
@JohnPeacock addressed this in his comment by saying dots should still be useable as an optional delimiter.
@hishamhm commented on GitHub (Jun 17, 2012):
@rstacruz, Sure. I know it doesn't matter to sort build hash numbers. The point is that it matters to sort version numbers. That's why build hashes don't belong in version numbers. I think there must be a well-defined sorting behavior for every token of a semantic version. After all, one of the main uses of standardized versioning is to allow versions to be mechanically sorted (as in solving "version > x" questions in dependency managers).
And yes, I agree that dots should be a valid delimiter, just like they are a delimiter in the major-minor-patch part.
@JohnPeacock commented on GitHub (Jun 17, 2012):
I wasn't thinking straight. I believed sorting hex numbers could be supported, but you are both correct that commit hashes cannot be allowed in external versions strings for the simple fact that they are not monotonically increasing. Hash's are by definition cannot be used as a uniquifier in version strings. If necessary for tracking purposes, they should be exposed internally only (e.g. the output of --version). I withdraw any suggestion of special handing for hex numbers.
And as to @hisham 's earlier comment, I wasn't suggesting that semantic versioning take all of the rules of rpmvercmp (that doc is historical, but it is easy enough to find the implementation code in either C or Python). I'm only suggesting that making dots a recommended but optional delimiter, and implicitly splitting on alpha and numeric sequences, that semantic versions could cover the vast majority of the existing RPM version landscape, yet be defined much more rigorously.
@JohnPeacock commented on GitHub (Jun 17, 2012):
I wasn't thinking straight. I believed sorting hex numbers could be supported, but you are both correct that commit hashes cannot be allowed in external versions strings for the simple fact that they are not monotonically increasing. Hash's are by definition cannot be used as a uniquifier in version strings. If necessary for tracking purposes, they should be exposed internally only (e.g. the output of --version). I withdraw any suggestion of special handing for hex numbers.
@hishamhm, as to earlier comment, I wasn't suggesting that semantic versioning take all of the rules of rpmvercmp (that doc is historical, but it is easy enough to find the implementation code in either C or Python). I'm only suggesting that making dots a recommended but optional delimiter, and implicitly splitting on alpha and numeric sequences, that semantic versions could cover the vast majority of the existing RPM version landscape, yet be defined much more rigorously.
@JohnPeacock commented on GitHub (Jun 17, 2012):
I wasn't thinking straight. I believed sorting hex numbers could be supported, but you are both correct that commit hashes cannot be allowed in external versions strings for the simple fact that they are not monotonically increasing. Hash's are by definition cannot be used as a uniquifier in version strings. If necessary for tracking purposes, they should be exposed internally only (e.g. the output of --version). I withdraw any suggestion of special handing for hex numbers.
@hishamhm, as to earlier comment, I wasn't suggesting that semantic versioning take all of the rules of rpmvercmp (that doc is historical, but it is easy enough to find the implementation code in either C or Python). I'm only suggesting that making dots a recommended but optional delimiter, and implicitly splitting on alpha and numeric sequences, that semantic versions could cover the vast majority of the existing RPM version landscape, yet be defined much more rigorously.
@JohnPeacock commented on GitHub (Jun 17, 2012):
Dammit. Sorry about that noise, the page wasn't updating for me...
@Omnikron13 commented on GitHub (Aug 11, 2012):
I'm quite surprised that nobody so far seems to have mentioned the fact that version strings such as '1.2.3-rc1' -are- technically compliant with the 2.0.0-rc.1 specification as it states 'Identifiers MUST be comprised of only ASCII alphanumerics and dash'.
The issue is that identifiers in the form 'rc[x]' would be sorted in ASCII sort order, which would result in (for example) the versions 1.2.3-rc1, 1.2.3-rc2 & 1.2.3-rc10 being ordered 1.2.3-rc2 > 1.2.3-rc10 > 1.2.3-rc1 instead of the intended order.
If you are confident in not exceeding rc9 then there is no particular reason not to label versions in this fashion, or if you are concerned with the possibility of exceeding rc9 then you could also potentially use rc01-rc99, all within the existing specification and sorting correctly.
These technical points aside I'm unsure as to your reason for raising this as an issue... The fact that existing projects are using version numbers such as '2.3.4-rc5' is irrelevant as far as semantic versioning is concerned because they shouldn't be considered compliant to semantic versioning unless they are complying with -all- the terms, including those relating to the public API and the circumstances version numbers change in, and they are unlikely to be compliant in all areas unless they are intentionally complying to semantic versioning. Projects electing to comply to semantic versioning can quite easily adopt the dot delimited indentifier format.
@rstacruz As far as hex is concerned the current specification would problematically consider some values as alphanumeric, and some as numeric, as already mentioned. If hexadecimal numeric identifiers were to be supported at all they should be required to be prefixed with '0x' to remove abiguity.
@JohnPeacock I'm also unsure as to your point regarding rpmvercmp, as from reading the page you linked it appears that all non-aphanumerics are treated as separators, so '1.2.3-rc.4' would be divided into 1, 2, 3, 'rc' & 4, and therefore compared correctly...
@haacked commented on GitHub (Dec 20, 2012):
Hi all. Coming in late to this thread. I'm not sure I understand the proposed change. @hishamhm, let me ask a simple question that might help me understand the proposal.
Under SemVer today,
1.0.0-rc.2<1.0.0-rc.10I think that's clear because the dot character explicitly separates the segment.
The following is also true as I understand it.
1.0.0-rc10<1.0.0-rc2Due to the "lexicographic ASCII sort order".
If I understand you correctly, you want to ensure that:
1.0.0-rc2<1.0.0-rc10I can see how that'd make sense. But given that this sort order is already enshrined in SemVer 1.0, I'm not sure it makes sense to change it for SemVer 2.0. That'd cause all sorts of problems for a huge number of people.