incrementing version numbers #169

New Issue

GiteaMirror · 2026-02-17T11:29:45-06:00

GiteaMirror commented

2026-02-17 11:29:45 -06:00

Originally created by @RoedyGreen on GitHub (Jan 27, 2015).

In various parts of the semver spec you talk of "incrementing version numbers". This could mean incrementing by 1 or incrementing by any positive integer. I wonder if you could clarify.

Personally I would like only incrementing by 1 so users can tell if they have been missing updates.

Originally created by @RoedyGreen on GitHub (Jan 27, 2015). In various parts of the semver spec you talk of "incrementing version numbers". This could mean incrementing by 1 or incrementing by any positive integer. I wonder if you could clarify. Personally I would like only incrementing by 1 so users can tell if they have been missing updates.

GiteaMirror closed this issue

2026-02-17 11:29:45 -06:00

GiteaMirror commented

2026-02-17 11:29:46 -06:00

@zafarkhaja commented on GitHub (Jan 27, 2015):

Sometimes a version number can be skipped for various reasons. PHP is one such example.

@zafarkhaja commented on GitHub (Jan 27, 2015): Sometimes a version number can be skipped for various reasons. PHP is one such [example](https://wiki.php.net/rfc/php6).

GiteaMirror commented

2026-02-17 11:29:46 -06:00

@stokito commented on GitHub (Aug 5, 2016):

It's good point - "incrementing" means adding one but it's not always possible.
For example OpenJDK uses even minor releases for new features (PSU) and odd for security fixes (CPU, Critical Patch Updates)
http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

Also sometimes version may me increased manually for marketing purposes.
And definitelly it may be gap in versions.
When for example v1.1 was released internally in company but declined by QA so next v1.2 was deployed to public repositories.
So if someone tries to find v1.1 it will fail.

That's why if you want to leave developers ability to change manually version then "incrementing" should be changed to "increasing".
But its should be considered carefully. Semver it's for machines, not peoples. It should be calculated automatically and people should't change versions themselves.

@stokito commented on GitHub (Aug 5, 2016): It's good point - "incrementing" means adding one but it's not always possible. For example OpenJDK uses even minor releases for new features (PSU) and odd for security fixes (CPU, Critical Patch Updates) http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html Also sometimes version may me increased manually for marketing purposes. And definitelly it may be gap in versions. When for example v1.1 was released internally in company but declined by QA so next v1.2 was deployed to public repositories. So if someone tries to find v1.1 it will fail. That's why if you want to leave developers ability to change manually version then "incrementing" should be changed to "increasing". But its should be considered carefully. Semver it's for machines, not peoples. It should be calculated automatically and people should't change versions themselves.

GiteaMirror commented

2026-02-17 11:29:47 -06:00

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

@RoedyGreen, I would add to the above, that there are workflows that require pre-allocation of major.minor versions to specific teams working on different features in the same sprint. At some point they get pulled into the major or master branch where yet another minor increment may occur for one or all of them.

If you have no further questions or comments, please close this issue at your earliest possible convenience.

@jwdonahue commented on GitHub (Dec 8, 2017): @RoedyGreen, I would add to the above, that there are workflows that require pre-allocation of major.minor versions to specific teams working on different features in the same sprint. At some point they get pulled into the major or master branch where yet another minor increment may occur for one or all of them. If you have no further questions or comments, please close this issue at your earliest possible convenience.