[GH-ISSUE #355] Uniform 0 usage across the components #7236

New Issue

GiteaMirror · 2026-06-20T17:08:28-05:00

GiteaMirror commented

2026-06-20 17:08:28 -05:00

Originally created by @libeako on GitHub (Feb 26, 2017).
Original GitHub issue: https://github.com/semver/semver/issues/355

The individual number components of the version should be used uniformly. Including that they should start from the same number [0 or 1].
Zero is an exceptional value, and we have a natural and important use case of it : not yet released. But this usage of zero is currently only in the first component of the version. The rest start from 0 even in released versions. IMO this is just a bad habit.
For example 1.3.0.5 should be a version of 1.3 which is not yet released.

Originally created by @libeako on GitHub (Feb 26, 2017). Original GitHub issue: https://github.com/semver/semver/issues/355 The individual number components of the version should be used uniformly. Including that they should start from the same number [0 or 1]. Zero is an exceptional value, and we have a natural and important use case of it : not yet released. But this usage of zero is currently only in the first component of the version. The rest start from 0 even in released versions. IMO this is just a bad habit. For example 1.3.0.5 should be a version of 1.3 which is not yet released.

GiteaMirror closed this issue

2026-06-20 17:08:29 -05:00

GiteaMirror commented

2026-06-20 17:08:30 -05:00

@marco-m commented on GitHub (Mar 17, 2017):

What you are referring to is called "pre-release version", see rule 9 of the specs. To follow your example, 1.3.0.5 would become 1.3.0-alpha.5 or whatever you find more appropriate for "alpha", like "pre-release".

@marco-m commented on GitHub (Mar 17, 2017): What you are referring to is called "pre-release version", see rule 9 of the specs. To follow your example, 1.3.0.5 would become 1.3.0-alpha.5 or whatever you find more appropriate for "alpha", like "pre-release".

GiteaMirror commented

2026-06-20 17:08:32 -05:00

@libeako commented on GitHub (Mar 18, 2017):

So development stage postfixes ["-beta", ...] are an alternative of what i am suggesting. But it is a bad alternative. A pure number version is much more simple. Simplicity is not only elegant, but it also is practical. Comparing of versions is important. For example in automatic package management. Comparing of pure number versions is considerably simpler than when dev-stage postfixes are involved. Comparing pure-number versions is not only trivially just a lexical sort, but also importantly : it is that intuitively for everyone. But when dev-stage postfixes are present then each package manager must explicitly define the allowed postfixes with their ordering and their users must learn and adopt them.

@libeako commented on GitHub (Mar 18, 2017): So development stage postfixes ["-beta", ...] are an alternative of what i am suggesting. But it is a bad alternative. A pure number version is much more simple. Simplicity is not only elegant, but it also is practical. Comparing of versions is important. For example in automatic package management. Comparing of pure number versions is considerably simpler than when dev-stage postfixes are involved. Comparing pure-number versions is not only trivially just a lexical sort, but also importantly : it is that intuitively for everyone. But when dev-stage postfixes are present then each package manager must explicitly define the allowed postfixes with their ordering and their users must learn and adopt them.

GiteaMirror commented

2026-06-20 17:08:34 -05:00

@FichteFoll commented on GitHub (Mar 18, 2017):

You are free to put whatever into your pre-release field. It could just be a number like 1.3.0-5.

Package managers can handle these situation without issues since they are trivial. The only thing the spec isn't clear about, iirc, is when an alphanumeric identifier needs to be compared with a purely numeric one. For my implementation, I chose to compare them lexicographically if one of the identifiers was not a number.

@FichteFoll commented on GitHub (Mar 18, 2017): You are free to put whatever into your pre-release field. It could just be a number like `1.3.0-5`. Package managers can handle these situation without issues since they are trivial. The only thing the spec isn't clear about, iirc, is when an alphanumeric identifier needs to be compared with a purely numeric one. For my implementation, I chose to compare them lexicographically if one of the identifiers was not a number.

GiteaMirror commented

2026-06-20 17:08:34 -05:00

@sschwarzer commented on GitHub (Jul 10, 2017):

@libeako You wrote, "Comparing pure-number versions is not only trivially just a lexical sort"

This isn't true if one of parts of the version number gets more digits. For example, "1.9.0" is an earlier release than "1.10.0", but "1.10.0" would sort lexically before "1.9.0".

@sschwarzer commented on GitHub (Jul 10, 2017): @libeako You wrote, "Comparing pure-number versions is not only trivially just a lexical sort" This isn't true if one of parts of the version number gets more digits. For example, "1.9.0" is an earlier release than "1.10.0", but "1.10.0" would sort lexically *before* "1.9.0".

GiteaMirror commented

2026-06-20 17:08:35 -05:00

@libeako commented on GitHub (Jul 10, 2017):

-> @sschwarzer : >>> ""1.10.0" would sort lexically before "1.9.0"" <<<

Only if you treat it as a text. But the canonical representation of a semantic version should not be text, because rendering into text loses semantics.
Instead it should be a sequence of nonnegative integers.

@libeako commented on GitHub (Jul 10, 2017): -> @sschwarzer : >>> ""1.10.0" would sort lexically before "1.9.0"" <<< Only if you treat it as a text. But the canonical representation of a semantic version should not be text, because rendering into text loses semantics. Instead it should be a sequence of nonnegative integers.

GiteaMirror commented

2026-06-20 17:08:36 -05:00

@sschwarzer commented on GitHub (Jul 10, 2017):

@libeako That's my point. I had understood you as saying that you could sensibly sort version strings lexically. So I guess we're on the same page now.

@sschwarzer commented on GitHub (Jul 10, 2017): @libeako That's my point. I had understood you as saying that you could sensibly sort version strings lexically. So I guess we're on the same page now.

GiteaMirror commented

2026-06-20 17:08:37 -05:00

@jwdonahue commented on GitHub (Nov 29, 2017):

@libeako

Semantic versions are strings representing numbers in the Major.Minor.Patch fields. It is an implementation detail if you convert those to a fixed width integer-type for comparisons. Given an ASCII or UTF-8 string encoding, comparing them without conversion is nearly trivial. Taking each field one at a time after first checking for extraneous leading zeros, simply compare their lengths, first, if one is longer it's definitely greater than the other, if they have the same length, simply compare them byte for byte until you find one that is greater.

Identifiers in the prerelease tag require classification into "is pure numeric" and "is alpha-numeric" categories. The spec says that pure numeric identifiers must be compared "numerically" and the mixed alpha-numeric identifiers, are to be compared lexically in ASCII sort order.

So you get exactly the behavior you are looking for if you adopt the convention that the first identifier in the prerelease tag is pure numeric. So you can have 1.3.0-5, and that is perfectly within the spec and gives you the semantics you seem to be looking for. Does this solve your problem? If so, please close this issue, otherwise, let's work through this to a conclusion.

@jwdonahue commented on GitHub (Nov 29, 2017): @libeako Semantic versions are strings representing numbers in the Major.Minor.Patch fields. It is an implementation detail if you convert those to a fixed width integer-type for comparisons. Given an ASCII or UTF-8 string encoding, comparing them without conversion is nearly trivial. Taking each field one at a time after first checking for extraneous leading zeros, simply compare their lengths, first, if one is longer it's definitely greater than the other, if they have the same length, simply compare them byte for byte until you find one that is greater. Identifiers in the prerelease tag require classification into "is pure numeric" and "is alpha-numeric" categories. The spec says that pure numeric identifiers must be compared "numerically" and the mixed alpha-numeric identifiers, are to be compared lexically in ASCII sort order. So you get exactly the behavior you are looking for if you adopt the convention that the first identifier in the prerelease tag is pure numeric. So you can have 1.3.0-5, and that is perfectly within the spec and gives you the semantics you seem to be looking for. Does this solve your problem? If so, please close this issue, otherwise, let's work through this to a conclusion.

GiteaMirror commented

2026-06-20 17:08:38 -05:00

@libeako commented on GitHub (Nov 29, 2017):

Now i read again the spec and realized that perhaps it does not exclude the usage i advocate. So this issue can be closed technically. I am sorry for having been holding you back with it.

I still believe in my suggestion. But now i see it as a cultural one, instead of technical. The rest of this comment is only interesting thoughts, and by it i do not intend to keep this issue open.

I see that people still do not understand my suggestion, so i will try again to explain. Just because i think it may be interesting thought for others too.

I know that one can implement any work-flow with the current scheme. But i want more. Of course i can make up custom pre-release format rules, for whatever complex versioning workflow i may need, and i am capable enough a programmer to parse and compare anything. My problem is not that i do not know how to use the current scheme, but that we could make it more simple and intuitive. By dropping the use of special format for pre-release versions and instead use number 0. According to my suggestion : the very first released version would be 1.1.1 instead of 1.0.0. I guess now you see that this is a cultural change, and a big one. People are very much used to 1.0, 2.0, ... . It is all over in our language and memory. My point is : it is just a bad habit.

This bad habit comes from a psychical trick human brain fell for. Often we speak about major versions only. Just like when speaking about distance, we say 1km instead of 1003m when precision is not important. The long, precise version of 1km is 1000m. So people got used to seeing zero digits after the most important digit. But this should not have been carried over to versioning, components of a version should not be interpreted as digits of a single number. The linear structure of all possible natural numbers is fundamentally different from the structure of all possible versions, which is a tree, in which the levels correspond to the components of the version. So carrying over the notation of distance [which is a single number] to version was a mental mistake.

But it happened and now is so strongly wired into the brains that people do not even understant what is wrong with it.

I suggest that 0 should designate the pre-release version, and 1 should designate the first release version at_all_levels.

Starting from 1 is actually natural and intuitive. One can test this by asking a person not yet affected by the programmers' habbit of starting from zero, like a 6 years old, to number his|her toys : [s]he will start from 1.

What i am suggesting with 0 is not without precedent, as it is already in the spec and the usage culture, however it is there only for the first component of the version. My suggestion is to extend this usage of 0 for the rest of the components too. By this we get rid of an inconsistency, making the scheme uniform, elegant from a mathematical point of view, which i firmly believe is the most important consideration in any design.

The usual versioning workflow throughout the product lifecycle would look like this :

0.x.x.x would mean a pre-release version under yet under heavy development, often change.
1.0.x.x would mean that the product is ready for release at the most important level, with other words : we are reasonably sure that backward compatibility will not be hurt by the further changes, the product is ready in its core design, but we still may be adding new features, with other words : it is in the alpha stage. The 0 at the second level would mean that this is not a released version, the product is still not ready to be released at the level where the 0 is, in this case : at the features level, the feature set is not ready yet.
1.1.0.x would mean that the product is ready at the features level too, we will not add new features, just debug, in other words : the product is in beta stage. The 0 would mean that the product is not yet ready at the quality level, we are still debugging, testing.
1.1.1 would mean the product is ready at the quality level too, so no more change is going to happen, it is ready for final release, with other words : it is the final version of the first public release.

Summing up the benefits of the suggested scheme: simplicity, no need for special pre-release format, hence no need for conventions [between cooperating tools, organizations], theoretical elegance, naturality. The only cost is a cultural change.

@libeako commented on GitHub (Nov 29, 2017): Now i read again the spec and realized that perhaps it does not exclude the usage i advocate. So this issue can be closed technically. I am sorry for having been holding you back with it. I still believe in my suggestion. But now i see it as a cultural one, instead of technical. The rest of this comment is only interesting thoughts, and by it i do not intend to keep this issue open. I see that people still do not understand my suggestion, so i will try again to explain. Just because i think it may be interesting thought for others too. I know that one can implement any work-flow with the current scheme. But i want more. Of course i can make up custom pre-release format rules, for whatever complex versioning workflow i may need, and i am capable enough a programmer to parse and compare anything. My problem is not that i do not know how to use the current scheme, but that we could make it more simple and intuitive. By dropping the use of special format for pre-release versions and instead use number 0. According to my suggestion : the very first released version would be 1.1.1 instead of 1.0.0. I guess now you see that this is a cultural change, and a big one. People are very much used to 1.0, 2.0, ... . It is all over in our language and memory. My point is : it is just a bad habit. This bad habit comes from a psychical trick human brain fell for. Often we speak about major versions only. Just like when speaking about distance, we say 1km instead of 1003m when precision is not important. The long, precise version of 1km is 1000m. So people got used to seeing zero digits after the most important digit. But this should not have been carried over to versioning, components of a version should not be interpreted as digits of a single number. The linear structure of all possible natural numbers is fundamentally different from the structure of all possible versions, which is a tree, in which the levels correspond to the components of the version. So carrying over the notation of distance [which is a single number] to version was a mental mistake. But it happened and now is so strongly wired into the brains that people do not even understant what is wrong with it. I suggest that 0 should designate the pre-release version, and 1 should designate the first release version _at_all_levels_. Starting from 1 is actually natural and intuitive. One can test this by asking a person not yet affected by the programmers' habbit of starting from zero, like a 6 years old, to number his|her toys : [s]he will start from 1. What i am suggesting with 0 is not without precedent, as it is already in the spec and the usage culture, however it is there only for the first component of the version. My suggestion is to extend this usage of 0 for the rest of the components too. By this we get rid of an inconsistency, making the scheme uniform, elegant from a mathematical point of view, which i firmly believe is the most important consideration in any design. The usual versioning workflow throughout the product lifecycle would look like this : * 0.x.x.x would mean a pre-release version under yet under heavy development, often change. * 1.0.x.x would mean that the product is ready for release at the most important level, with other words : we are reasonably sure that backward compatibility will not be hurt by the further changes, the product is ready in its core design, but we still may be adding new features, with other words : it is in the alpha stage. The 0 at the second level would mean that this is not a released version, the product is still not ready to be released at the level where the 0 is, in this case : at the features level, the feature set is not ready yet. * 1.1.0.x would mean that the product is ready at the features level too, we will not add new features, just debug, in other words : the product is in beta stage. The 0 would mean that the product is not yet ready at the quality level, we are still debugging, testing. * 1.1.1 would mean the product is ready at the quality level too, so no more change is going to happen, it is ready for final release, with other words : it is the final version of the first public release. Summing up the benefits of the suggested scheme: simplicity, no need for special pre-release format, hence no need for conventions [between cooperating tools, organizations], theoretical elegance, naturality. The only cost is a cultural change.

GiteaMirror commented

2026-06-20 17:08:38 -05:00

@jwdonahue commented on GitHub (Nov 29, 2017):

So let's take that a step further, you ended with 1.1.1, now my teams start working on the next sprint, we're going to do A/B flight testing with our most risk resilient ring 0 dogfooders, what are the version numbers for the A and B series of bits? Keep in mind, they have different versions of the same feature set and will have different bugs that will have to be patched before the series can move to rings 1 and 2.

@jwdonahue commented on GitHub (Nov 29, 2017): So let's take that a step further, you ended with 1.1.1, now my teams start working on the next sprint, we're going to do A/B flight testing with our most risk resilient ring 0 dogfooders, what are the version numbers for the A and B series of bits? Keep in mind, they have different versions of the same feature set and will have different bugs that will have to be patched before the series can move to rings 1 and 2.

GiteaMirror commented

2026-06-20 17:08:39 -05:00

@libeako commented on GitHub (Nov 29, 2017):

@jwdonahue ,
Sorry, i simply did not understand the scenario you described.
But i try to react to what i feel like you may have meant:
A possible new stage [dogfooding] can be naturally handled by my scheme, just introduce a new component for it in the pre-release versions.
Parallely developed versions is more difficult to handle, because they by their nature can not be ordered, while i intended my simple scheme to be fully ordered, and so is the current semver spec.

@libeako commented on GitHub (Nov 29, 2017): @jwdonahue , Sorry, i simply did not understand the scenario you described. But i try to react to what i feel like you may have meant: A possible new stage [dogfooding] can be naturally handled by my scheme, just introduce a new component for it in the pre-release versions. Parallely developed versions is more difficult to handle, because they by their nature can not be ordered, while i intended my simple scheme to be fully ordered, and so is the current semver spec.

GiteaMirror commented

2026-06-20 17:08:40 -05:00

@jwdonahue commented on GitHub (Nov 29, 2017):

@libeako, so you're saying to do something like 1.1.1-A and 1.1.1-B ?

@jwdonahue commented on GitHub (Nov 29, 2017): @libeako, so you're saying to do something like 1.1.1-A and 1.1.1-B ?

GiteaMirror commented

2026-06-20 17:08:41 -05:00

@libeako commented on GitHub (Nov 30, 2017):

Mathematically it does not change anything if i replace the special format [letters after a hyphen] with regular numbers. Because by the current spec non-numerical characters compare too. So instead of {1.1.1-A, 1.1.1-B} one can use {1.1.1.m, 1.1.1.n} where m, n are numbers. So using letters do not gain anything, but complicate the syntax. Using letters instead of numbers would make good sense to me if they were not comparable. I wish a clear distinction of roles : numbers for sequential versions, letters for parallel versions. Then i would be a friend of letters. Pre-release is a sequential version distinction compared to released, hence (according to my suggestion) letters should not be used for its designation.
According to my suggested scheme and if one considers dogfooding to be a pre-release [late-beta] stage, then one should use {1.1.1.0.m, 1.1.1.0,n} [notice the 0s]. In this 1 as the 3rd component indicates that the product is ready at the "usual" beta stage, and the 0 as the 4th component indicates that the product is not yet ready with the dogfooding stage. The component count incrementation of the version (that you may notice here) reflects the introduction of a development stage [dogfooding] which is new in our discussion. As usual : a 0 anywhere in the version indicates the version to be not fully ready for real release; the most significant 0 position tells us the major development stage the version is in.

@libeako commented on GitHub (Nov 30, 2017): 1) Mathematically it does not change anything if i replace the special format [letters after a hyphen] with regular numbers. Because by the current spec non-numerical characters compare too. So instead of {1.1.1-A, 1.1.1-B} one can use {1.1.1.m, 1.1.1.n} where m, n are numbers. So using letters do not gain anything, but complicate the syntax. Using letters instead of numbers would make good sense to me if they were not comparable. I wish a clear distinction of roles : numbers for sequential versions, letters for parallel versions. Then i would be a friend of letters. Pre-release is a sequential version distinction compared to released, hence (according to my suggestion) letters should not be used for its designation. 2) According to my suggested scheme and if one considers dogfooding to be a pre-release [late-beta] stage, then one should use {1.1.1.0.m, 1.1.1.0,n} [notice the 0s]. In this 1 as the 3rd component indicates that the product is ready at the "usual" beta stage, and the 0 as the 4th component indicates that the product is not yet ready with the dogfooding stage. The component count incrementation of the version (that you may notice here) reflects the introduction of a development stage [dogfooding] which is new in our discussion. As usual : a 0 anywhere in the version indicates the version to be not fully ready for real release; the most significant 0 position tells us the major development stage the version is in.

GiteaMirror commented

2026-06-20 17:08:42 -05:00

@jwdonahue commented on GitHub (Nov 30, 2017):

@libeako
In semver, everything after the first hyphen is a prerelease tag and there is a well defined precedence for those, whether they are numeric or alpha-numeric. You seem to be saying that you would add more dotted numeric fields to the left side of the string, is that correct? Would you eliminate the prerelease tag in that case?

@jwdonahue commented on GitHub (Nov 30, 2017): @libeako In semver, everything after the first hyphen is a prerelease tag and there is a well defined precedence for those, whether they are numeric or alpha-numeric. You seem to be saying that you would add more dotted numeric fields to the left side of the string, is that correct? Would you eliminate the prerelease tag in that case?

GiteaMirror commented

2026-06-20 17:08:43 -05:00

@FichteFoll commented on GitHub (Nov 30, 2017):

This looks like an odd attempt at trying to replace the pre-release section with a seemingly arbitrary number of more fields and a more complex rule for determining whether something is still in development and not ready for release.

By the way, you are free to use whatever version versioning scheme you want internally. Semver is only for external communication regarding the changes between two releases.

@FichteFoll commented on GitHub (Nov 30, 2017): This looks like an odd attempt at trying to replace the pre-release section with a seemingly arbitrary number of more fields and a more complex rule for determining whether something is still in development and not ready for release. By the way, you are free to use whatever version versioning scheme you want internally. Semver is only for external communication regarding the changes between two releases.

GiteaMirror commented

2026-06-20 17:08:44 -05:00

@jwdonahue commented on GitHub (Nov 30, 2017):

@FichteFoll, I agree with your assessment.
@libeako, the prerelease tag is an unambiguous indication that the version is not finished baking. You can pretty much use any convention you want there. You don't have to use -beta or -alpha, you can use -0.1 if that is your preference.

I predict this will never get approved, please close this issue at your earliest convenience.

@jwdonahue commented on GitHub (Nov 30, 2017): @FichteFoll, I agree with your assessment. @libeako, the prerelease tag is an unambiguous indication that the version is not finished baking. You can pretty much use any convention you want there. You don't have to use -beta or -alpha, you can use -0.1 if that is your preference. I predict this will never get approved, please close this issue at your earliest convenience.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#7236