Comparing 1.5.9 and 2.0.0-alpha #31

New Issue

GiteaMirror · 2026-02-17T11:03:55-06:00

GiteaMirror commented

2026-02-17 11:03:55 -06:00

Originally created by @ghost on GitHub (Jul 24, 2012).

Is 1.5.9 greater or less than 2.0.0-alpha (or -beta, or -rc)?

I'm assuming it is greater.

Originally created by @ghost on GitHub (Jul 24, 2012). Is `1.5.9` greater or less than `2.0.0-alpha` (or `-beta`, or `-rc`)? I'm assuming it is greater.

GiteaMirror closed this issue

2026-02-17 11:03:55 -06:00

GiteaMirror commented

2026-02-17 11:03:56 -06:00

@TheRealEdwardCullen commented on GitHub (Jul 27, 2012):

See paragraph 12.

HINT: Which of the two has a higher Major version number?

@TheRealEdwardCullen commented on GitHub (Jul 27, 2012): See paragraph 12. HINT: Which of the two has a higher Major version number?

GiteaMirror commented

2026-02-17 11:03:57 -06:00

@ghost commented on GitHub (Jul 27, 2012):

To anyone else wondering what the answer to the question is, it's no.

As described in paragraph 12, an unstable version has a higher precedence than stable software of a prior major version.

If your application is checking for updates, you may want to consider locking it to the current major version.

@ghost commented on GitHub (Jul 27, 2012): To anyone else wondering what the answer to the question is, it's **no**. As described in paragraph 12, an unstable version has a higher precedence than stable software of a prior major version. If your application is checking for updates, you may want to consider locking it to the current major version.

GiteaMirror commented

2026-02-17 11:03:57 -06:00

@chickenandpork commented on GitHub (Oct 30, 2012):

This is actually better handled by proper use of the "99" versioning convent:

1.2.3-pre1 is actually 1.2.2.99.1 as it's a pre-bump public check of a 1.2.2 release -based candidate to a 1.2.3 codebase

1.2.3-pre2 is actually 1.2.2.99.2
1.2.3-pre3 is actually 1.2.2.99.3
when the pre-rc-alpha-beta stuff are finished, 1.2.2.99.x rolls up to 1.2.3 (.0.0)

This preserves basic trivial comparisons, yet nicely converts unnecessary meatware-oriented versioning to basic logic that withstands the basic A > B test. Honestly, "pre", "rc", "alpha", "beta", are all oriented towards human readers, but not towards calculation-oriented architectures.

To restate OP's question:

"Is 1.5.9 greater or less than 1.99.0.1 (or 1.99.0.2 or 1.99.0.3) ?"

Please consider and offer some thoughts. I haven't seen this common convention discussed in SemVer.

@chickenandpork commented on GitHub (Oct 30, 2012): This is actually better handled by proper use of the "99" versioning convent: 1.2.3-pre1 is actually 1.2.2.99.1 as it's a pre-bump public check of a 1.2.2 release -based candidate to a 1.2.3 codebase 1.2.3-pre2 is actually 1.2.2.99.2 1.2.3-pre3 is actually 1.2.2.99.3 when the pre-rc-alpha-beta stuff are finished, 1.2.2.99.x rolls up to 1.2.3 (.0.0) This preserves basic trivial comparisons, yet nicely converts unnecessary meatware-oriented versioning to basic logic that withstands the basic A > B test. Honestly, "pre", "rc", "alpha", "beta", are all oriented towards human readers, but not towards calculation-oriented architectures. To restate OP's question: "Is 1.5.9 greater or less than 1.99.0.1 (or 1.99.0.2 or 1.99.0.3) ?" Please consider and offer some thoughts. I haven't seen this common convention discussed in SemVer.

GiteaMirror commented

2026-02-17 11:03:58 -06:00

@TheRealEdwardCullen commented on GitHub (Oct 30, 2012):

chickenandpork wrote

Honestly, "pre", "rc", "alpha", "beta", are all oriented towards human readers, but not towards calculation-oriented architectures.

True, but that is the intention of SemVer.

SemVer has one and only one purpose, creating a unambiguous versioning scheme that human beings can understand and can use to make judgements on the nature of a change purely based on version numbers. How implementations, such as package managers, handle this is a secondary concern. In fact, I would argue that the whole issue of package management is so complex that it should be ignored when thinking about SemVer (well, almost completely ignored).

My understanding of the "99" convention is that it's a kludge to work-around deficiencies in RPM &&|| DEB, so that package distributors can have a nice progression in their software versions; a case of "fitting the process around the tools", which is what SemVer is trying to get away from.

I would also argue that, while SemVer provides a mapping mechanism, in practice, using this for tooling is a mistake as it over-simplifies something very complex (i.e. I need to be able to maintain parallel installations of different ABI versions of libraries; naive use of 2.x.x > 1.x.x is no good to me).

@TheRealEdwardCullen commented on GitHub (Oct 30, 2012): chickenandpork wrote > Honestly, "pre", "rc", "alpha", "beta", are all oriented towards human readers, but not towards calculation-oriented architectures. True, but that is the intention of SemVer. SemVer has one and only one purpose, creating a unambiguous versioning scheme that human beings can understand and can use to make judgements on the nature of a change purely based on version numbers. How implementations, such as package managers, handle this is a secondary concern. In fact, I would argue that the whole issue of package management is so complex that it should be ignored when thinking about SemVer (well, almost completely ignored). My understanding of the "99" convention is that it's a kludge to work-around deficiencies in RPM &&|| DEB, so that package distributors can have a nice progression in their software versions; a case of "fitting the process around the tools", which is what SemVer is trying to get away from. I would also argue that, while SemVer provides a mapping mechanism, in practice, using this for tooling is a mistake as it over-simplifies something very complex (i.e. I _need_ to be able to maintain parallel installations of different ABI versions of libraries; naive use of 2.x.x > 1.x.x is no good to me).

GiteaMirror commented

2026-02-17 11:03:58 -06:00

@Tieske commented on GitHub (Oct 30, 2012):

@chickenandpork Won't work if you ask me;
if 1.99.0.1 gets its final release as 2.0.0, then the latter (the 2.0.0) indicates an incompatibility with previous versions. So the 1.99.0.1 breaks the compatibility rule because it is in the 1.x range, whilst not being backward compatible (it's the same code as 2.0.0).

@Tieske commented on GitHub (Oct 30, 2012): @chickenandpork Won't work if you ask me; if 1.99.0.1 gets its final release as 2.0.0, then the latter (the 2.0.0) indicates an incompatibility with previous versions. So the 1.99.0.1 breaks the compatibility rule because it is in the 1.x range, whilst not being backward compatible (it's the same code as 2.0.0).

GiteaMirror commented

2026-02-17 11:03:59 -06:00

@chickenandpork commented on GitHub (Nov 3, 2012):

the 99 convention is to work around the human desire to complicate versioning. Truly autonomous versioning only needs monotonically-incrementing numbers. It's humans who need the dots.

You could just as easily maintain any two versions concurrently so long as their versions were not strcmp() equal.

I've seen other posters ask for a simple way to choose whether one version supersedes another, but the message is lost there:

a versioning that only works for people is pretty, but breaks with packagers
a versioning that works with packagers isn't pretty enough for people
if API version is hidden in the version, then you really have all APIs and ABIs monotonically increasing lock-step on your trunk. No worries

I would counter with:

do rc versions last forever, or should they be replaced?
can people understand that a version including 99 might not be API -compliant?

does your versioning permit a 2.0.0.-1.4 as a 2.0.0-pre4 markup? That handles all three cases:

monotonically increasing
enough dots for people
API compatibility can still be the trunk major.minor

FYC

Allan

On 2012-10-30, at 5:29, TheRealEdwardCullen notifications@github.com wrote:

chickenandpork wrote

Honestly, "pre", "rc", "alpha", "beta", are all oriented towards human readers, but not towards calculation-oriented architectures.

True, but that is the intention of SemVer.

SemVer has one and only one purpose, creating a unambiguous versioning scheme that human beings can understand and can use to make judgements on the nature of a change purely based on version numbers. How implementations, such as package managers, handle this is a secondary concern. In fact, I would argue that the whole issue of package management is so complex that it should be ignored when thinking about SemVer (well, almost completely ignored).

My understanding of the "99" convention is that it's a kludge to work-around deficiencies in RPM &&|| DEB, so that package distributors can have a nice progression in their software versions; a case of "fitting the process around the tools", which is what SemVer is trying to get away from.

I would also argue that, while SemVer provides a mapping mechanism, in practice, using this for tooling is a mistake as it over-simplifies something very complex (i.e. I need to be able to maintain parallel installations of different ABI versions of libraries; naive use of 2.x.x > 1.x.x is no good to me).

Reply to this email directly or view it on GitHub.

@chickenandpork commented on GitHub (Nov 3, 2012): the 99 convention is to work around the human desire to complicate versioning. Truly autonomous versioning only needs monotonically-incrementing numbers. It's humans who need the dots. You could just as easily maintain any two versions concurrently so long as their versions were not strcmp() equal. I've seen other posters ask for a simple way to choose whether one version supersedes another, but the message is lost there: 1) a versioning that only works for people is pretty, but breaks with packagers 2) a versioning that works with packagers isn't pretty enough for people 3) if API version is hidden in the version, then you really have all APIs and ABIs monotonically increasing lock-step on your trunk. No worries I would counter with: 1) do rc versions last forever, or should they be replaced? 2) can people understand that a version including 99 might not be API -compliant? does your versioning permit a 2.0.0.-1.4 as a 2.0.0-pre4 markup? That handles all three cases: 1) monotonically increasing 2) enough dots for people 3) API compatibility can still be the trunk major.minor FYC Allan On 2012-10-30, at 5:29, TheRealEdwardCullen notifications@github.com wrote: > chickenandpork wrote > > Honestly, "pre", "rc", "alpha", "beta", are all oriented towards human readers, but not towards calculation-oriented architectures. > > True, but that is the intention of SemVer. > > SemVer has one and only one purpose, creating a unambiguous versioning scheme that human beings can understand and can use to make judgements on the nature of a change purely based on version numbers. How implementations, such as package managers, handle this is a secondary concern. In fact, I would argue that the whole issue of package management is so complex that it should be ignored when thinking about SemVer (well, almost completely ignored). > > My understanding of the "99" convention is that it's a kludge to work-around deficiencies in RPM &&|| DEB, so that package distributors can have a nice progression in their software versions; a case of "fitting the process around the tools", which is what SemVer is trying to get away from. > > I would also argue that, while SemVer provides a mapping mechanism, in practice, using this for tooling is a mistake as it over-simplifies something very complex (i.e. I need to be able to maintain parallel installations of different ABI versions of libraries; naive use of 2.x.x > 1.x.x is no good to me). > > \ > Reply to this email directly or view it on GitHub.

GiteaMirror commented

2026-02-17 11:04:00 -06:00

@Tieske commented on GitHub (Nov 3, 2012):

Actually I think there should be a distinction between order of development and the API compatibility. They are 2 different things, wrapped within semver. see #28

@Tieske commented on GitHub (Nov 3, 2012): Actually I think there should be a distinction between order of development and the API compatibility. They are 2 different things, wrapped within semver. see #28

GiteaMirror referenced this issue

2026-02-17 12:17:22 -06:00

[PR #31] [CLOSED] remove inapplicable “Remember” in FAQ #715

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#31