[GH-ISSUE #165] Define strict ordering rules on prerelease version names #1841

New Issue

GiteaMirror · 2026-04-20T09:30:45-05:00

GiteaMirror commented

2026-04-20 09:30:45 -05:00

Originally created by @TimLovellSmith on GitHub (Oct 22, 2013).
Original GitHub issue: https://github.com/semver/semver/issues/165

Xavier Decoster notes (http://msdn.microsoft.com/en-us/magazine/jj851071.aspx
)

"For prerelease packages, the reason for not using a fourth build number is simple: NuGet doesn’t support build numbers in prereleases. You can’t create a NuGet package in the format major.minor.patch-prerelease.build or major.minor.patch-prerelease+build. Any other attempt to auto-increment a prerelease package using a build number will most likely fail because the version precedence algorithm is sorting prerelease tags in alphabetical order. This effectively means, for example, that v1.0.0-alpha2> v1.0.0-alpha10> v1.0.0-alpha02 (which brings me to the next rule, as you’ll see in a bit)."

I think it would be great if nuget understood that alpha10 or alpha-10 or alpha.10 is greater than alpha02 (etc.).

I would like to suggest that for semver3

'A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.'

Be amended to note:

Identifiers are treated as separate numeric and non-numeric parts when they contain both types of characters. Numeric parts MUST NOT contain leading zeros.

Precedence ordering is alphabetic (lexicographic) for non-numeric parts, and numeric for numeric parts. And numerically named parts will precede non-numeric.
e.g.:
1.0.0-alpha <
1.0.0-alpha1 <
1.0.0-alpha2 <
...
< 1.0.0-alpha10
< 1.0.0-alpha10.1
< 1.0.0-alpha10.x
< 1.0.0-alpha10.x1

And recommend: numeric parts SHOULD appear once per identifier and only at the end of the identifier.

Originally created by @TimLovellSmith on GitHub (Oct 22, 2013). Original GitHub issue: https://github.com/semver/semver/issues/165 Xavier Decoster notes (http://msdn.microsoft.com/en-us/magazine/jj851071.aspx ) "For prerelease packages, the reason for not using a fourth build number is simple: NuGet doesn’t support build numbers in prereleases. You can’t create a NuGet package in the format major.minor.patch-prerelease.build or major.minor.patch-prerelease+build. Any other attempt to auto-increment a prerelease package using a build number will most likely fail because **the version precedence algorithm is sorting prerelease tags in alphabetical order**. This effectively means, for example, that v1.0.0-alpha2> v1.0.0-alpha10> v1.0.0-alpha02 (which brings me to the next rule, as you’ll see in a bit)." I think it would be great if nuget understood that alpha10 or alpha-10 or alpha.10 is greater than alpha02 (etc.). I would like to suggest that for semver3 'A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.' Be amended to note: Identifiers are treated as separate numeric and non-numeric parts when they contain both types of characters. Numeric parts MUST NOT contain leading zeros. Precedence ordering is alphabetic (lexicographic) for non-numeric parts, and numeric for numeric parts. And numerically named parts will precede non-numeric. e.g.: 1.0.0-alpha < 1.0.0-alpha1 < 1.0.0-alpha2 < ... < 1.0.0-alpha10 < 1.0.0-alpha10.1 < 1.0.0-alpha10.x < 1.0.0-alpha10.x1 And recommend: numeric parts SHOULD appear once per identifier and only at the end of the identifier.

GiteaMirror closed this issue

2026-04-20 09:30:46 -05:00

GiteaMirror commented

2026-04-20 09:30:47 -05:00

@konstantinbe commented on GitHub (May 14, 2014):

I was just about to open an issue to suggest exactly the same, i.e. change precedence ordering to be numeric for numeric parts of an identifier. This change will make Semantic Versioning a bit more "human-friendly" since using common sense 1.0.0-alpha-9 clearly is < than 1.0.0-alpha-11.

Also, I do like the recommendation of having just one numeric part at the end of an identifier.

@konstantinbe commented on GitHub (May 14, 2014): I was just about to open an issue to suggest exactly the same, i.e. change precedence ordering to be _numeric_ for numeric parts of an identifier. This change will make Semantic Versioning a bit more "human-friendly" since using common sense `1.0.0-alpha-9` clearly is `<` than `1.0.0-alpha-11`. Also, I do like the recommendation of having just one numeric part at the end of an identifier.

GiteaMirror commented

2026-04-20 09:30:47 -05:00

@FichteFoll commented on GitHub (May 15, 2014):

What is the reason that you can not use 1.0.0-alpha.2 and 1.0.0-alpha.10 respectively?

Edit: Saw it after reading again:

You can’t create a NuGet package in the format major.minor.patch-prerelease.build

So you need this to circumvent a limitation in NuGet, is that correct? (I'd rather have NuGet implement semver than semver respect NuGet's restrictions.)

@FichteFoll commented on GitHub (May 15, 2014): What is the reason that you can not use `1.0.0-alpha.2` and `1.0.0-alpha.10` respectively? Edit: Saw it after reading again: > You can’t create a NuGet package in the format major.minor.patch-prerelease.build So you need this to circumvent a limitation in NuGet, is that correct? (I'd rather have NuGet implement semver than semver respect NuGet's restrictions.)

GiteaMirror commented

2026-04-20 09:30:48 -05:00

@damianpowell commented on GitHub (May 15, 2014):

I agree with @FichteFoll. NuGet should respect SemVer, not the other way around. SemVer already has a well defined notion of identifiers within prerelease and build metadata (sections 9 & 10 on semver.org). If we need to sort in numeric order we should use a numeric identifier in the prerelease tag, such as "1.0.0-alpha.2". This of course requires an updated to NuGet's shoddy version parsing and sorting! The sorting rules are also defined such that 1.0.0-alpha.2 and 1.0.0-alpha.10 would appear in the appropriate order (section 11 on semver.org).

@damianpowell commented on GitHub (May 15, 2014): I agree with @FichteFoll. NuGet should respect SemVer, not the other way around. SemVer already has a well defined notion of identifiers _within_ prerelease and build metadata (sections 9 & 10 on semver.org). If we need to sort in numeric order we should use a numeric identifier in the prerelease tag, such as "1.0.0-alpha.2". This of course requires an updated to NuGet's shoddy version parsing and sorting! The sorting rules are also defined such that 1.0.0-alpha.2 and 1.0.0-alpha.10 would appear in the appropriate order (section 11 on semver.org).

GiteaMirror commented

2026-04-20 09:30:48 -05:00

@TimLovellSmith commented on GitHub (May 15, 2014):

@FichteFoll Well, yes, it is currently the case of semver and NuGet both don't support the build number scenario. And indeed the semver spec doesn't declare any precedence ordering on prerelease versions in relation to each other. For instance the idea of doing an 'upgrade' between prerelease versions is not based on any sound notion in the semver spec about which prerelease version is newer.

Basically: I would just like it to be true that 1.0.0-alpha2 always logically precedes 1.0.0-alpha10 - and if I do a prerelease package upgrade I know which one will be the package that gets installed.

@TimLovellSmith commented on GitHub (May 15, 2014): @FichteFoll Well, yes, it is currently the case of semver and NuGet both don't support the build number scenario. And indeed the semver spec doesn't declare any precedence ordering on prerelease versions in relation to _each other_. For instance the idea of doing an 'upgrade' between prerelease versions is not based on any sound notion in the semver spec about which prerelease version is newer. Basically: I would just like it to be true that 1.0.0-alpha2 always logically precedes 1.0.0-alpha10 - and if I do a prerelease package upgrade I know which one will be the package that gets installed.

GiteaMirror commented

2026-04-20 09:30:49 -05:00

@FichteFoll commented on GitHub (May 15, 2014):

semver does support the build number scenario very well, just not in the very format you have.

You see, standards are there to be used and to give a simple yet precise definition of it. If the standard had to be adjusted for all special cases it would become way to complex because there are so many special cases in the world.

semver aims to combine many of the features you could need into a simple standard, which is called semantic versioning. If something does not follow these standards or they were simply not there when it was initially created then the different strategies will likely differ. However, it is the tool that should be made comform to the standard and not the standard to all existing tools.

This discussion arises on this repo a lot and it eventually boils down to this very same argument, or at least it should.

Anyway, coming back to this particular example: The feature you want/try to achieve is already defined in semver, it's just a different format. In which case you could want to debate the format itself but I think we all agree that alpha.10 is both easier to read and easier to specify (in a standard).

(I don't feel like I got the message across very well.)

@FichteFoll commented on GitHub (May 15, 2014): semver does support the build number scenario very well, just not in the very format you have. You see, standards are there to be used and to give a simple yet precise definition of it. If the standard had to be adjusted for all special cases it would become way to complex because there are so many special cases in the world. semver aims to combine many of the features you could need into a simple standard, which is called semantic versioning. If something does not follow these standards or they were simply not there when it was initially created then the different strategies will likely differ. However, it is the tool that should be made comform to the standard and not the standard to all existing tools. This discussion arises on this repo a lot and it eventually boils down to this very same argument, or at least it should. Anyway, coming back to this particular example: The feature you want/try to achieve is already defined in semver, it's just a different format. In which case you could want to debate the format itself but I think we all agree that `alpha.10` is both easier to read and easier to specify (in a standard). (I don't feel like I got the message across very well.)

GiteaMirror commented

2026-04-20 09:30:50 -05:00

@konstantinbe commented on GitHub (May 15, 2014):

@FichteFoll I personally understand your point very well and in general I do support it. However, alpha-10 is in my opinion a more natural and simpler way (or format) to specify the "10th alpha". Making it part of the standard results in (1) better readability and (2) makes it much more compatible with existing versioning schemes without adding much complexity. In this case, I think it is worth it.

@konstantinbe commented on GitHub (May 15, 2014): @FichteFoll I personally understand your point very well and in general I do support it. However, `alpha-10` is in my opinion a more natural and simpler way (or _format_) to specify the "10th alpha". Making it part of the standard results in (1) better _readability_ and (2) makes it much more _compatible_ with existing versioning schemes _without_ adding much complexity. In this case, I think it is worth it.

GiteaMirror commented

2026-04-20 09:30:51 -05:00

@FichteFoll commented on GitHub (May 15, 2014):

So you are thinking of also allowing - to split version fractions in pre-releases alongside .? That is debatable I guess (and I don't have strong opinions in this case) but a different issue.

@FichteFoll commented on GitHub (May 15, 2014): So you are thinking of also allowing `-` to split version fractions in pre-releases alongside `.`? That is debatable I guess (and I don't have strong opinions in this case) but a different issue.

GiteaMirror commented

2026-04-20 09:30:51 -05:00

@jwdonahue commented on GitHub (Dec 3, 2017):

@TimLovellSmith, I don't believe there is much chance of a change being taken on this one. Unless you intend to issue PR or have questions, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Dec 3, 2017): @TimLovellSmith, I don't believe there is much chance of a change being taken on this one. Unless you intend to issue PR or have questions, please close this issue at your earliest possible convenience.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#1841