[GH-ISSUE #803] Support for more granular releases than <patch> level #6519

New Issue

GiteaMirror · 2026-06-17T05:21:19-05:00

GiteaMirror commented

2026-06-17 05:21:19 -05:00

Originally created by @RichiH on GitHub (Feb 16, 2022).
Original GitHub issue: https://github.com/semver/semver/issues/803

https://github.com/grafana/grafana/ and other Grafana projects structure security releases as follows:

Fix security issue in codebase
Create private x.y.z+1 (+1 used in the "integer plus one" sense here) release -- which contains security-relevant changes only
Release x.y.z+1 to the public one week later

Normal development runs in parallel, but other releases are blocked until x.y.z+1 is public. x.y.z+2 often comes out at the same time as x.y.z+1. The intention behind this system is to allow users to immediately install security updates with the minimal internal Q&A.

The problem is that blocking normal releases slows down everything else.

Possible approaches:

Release non-security patch releases as with even z, any potential security patches with uneven z. This feels like what Linux 2.x did and it's confusing to many users. It also makes follow-up security patches for this specific version impossible.
Release x.y.z+security01 (+security01 used in the "build info" sense here). This allows for clear signalling to users and has enough room for potential follow-up updates. The problem is that build info MUST NOT be used for determining version precedence. As such, this is a human-readable indicator, but not useful for wider automation.
Skip x.y.z+1 for a week, releasing x.y.z+2 before it. This signals the existence of an upcoming security release.

I see two possible changes to SemVer which would enable this and similar use cases:

Allow x.y.z[.a], i.e.

<version core> ::= <major> "." <minor> "." <patch>
                 | <major> "." <minor> "." <patch> "." <subpatch>
<subpatch> ::= <numeric identifier>

Introduce an alphanumeric suffix which MUST be used to determine precendence, e.g. + or _ similar to how Debian versioning works semantically, i.e.

<valid semver> ::= <version core>
                 | <version core> "-" <pre-release>
                 | <version core> "+" <build>
                 | <version core> "-" <pre-release> "+" <build>
                 | <version core> "_" <subpatch>
                 | <version core> "_" <subpatch> "-" <pre-release>
                 | <version core> "_" <subpatch> "-" <pre-release> "+" <build>
<subpatch> :== <build identifier>

The more generic and widely usable system seems to be option 1.

NB: "subpatch" is the least bad name I could come up with just now. It's not particularly good.
NB: Both of those suggestions would be breaking changes for SemVer, requiring a new major version.

If there's any interest in this, I would be more than happy to work on a RFC/PR.

Originally created by @RichiH on GitHub (Feb 16, 2022). Original GitHub issue: https://github.com/semver/semver/issues/803 https://github.com/grafana/grafana/ and other Grafana projects structure security releases as follows: * Fix security issue in codebase * Create private `x.y.z+1` (`+1` used in the "integer plus one" sense here) release -- which contains security-relevant changes *only* * Release `x.y.z+1` to the public one week later Normal development runs in parallel, but other releases are blocked until `x.y.z+1` is public. `x.y.z+2` often comes out at the same time as `x.y.z+1`. The intention behind this system is to allow users to immediately install security updates with the minimal internal Q&A. The problem is that blocking normal releases slows down everything else. Possible approaches: 1. Release non-security patch releases as with even z, any potential security patches with uneven z. This feels like what Linux 2.x did and it's confusing to many users. It also makes follow-up security patches for this specific version impossible. 2. Release `x.y.z+security01` (`+security01` used in the "build info" sense here). This allows for clear signalling to users and has enough room for potential follow-up updates. The problem is that build info MUST NOT be used for determining version precedence. As such, this is a human-readable indicator, but not useful for wider automation. 3. Skip `x.y.z+1` for a week, releasing `x.y.z+2` before it. This signals the existence of an upcoming security release. I see two possible changes to SemVer which would enable this and similar use cases: 1. Allow x.y.z[.a], i.e. ```` <version core> ::= <major> "." <minor> "." <patch> | <major> "." <minor> "." <patch> "." <subpatch> <subpatch> ::= <numeric identifier> ```` 2. Introduce an alphanumeric suffix which MUST be used to determine precendence, e.g. `+` or `_` similar to how Debian versioning works semantically, i.e. ```` <valid semver> ::= <version core> | <version core> "-" <pre-release> | <version core> "+" <build> | <version core> "-" <pre-release> "+" <build> | <version core> "_" <subpatch> | <version core> "_" <subpatch> "-" <pre-release> | <version core> "_" <subpatch> "-" <pre-release> "+" <build> <subpatch> :== <build identifier> ```` The more generic and widely usable system seems to be option 1. NB: "subpatch" is the least bad name I could come up with just now. It's not particularly good. NB: Both of those suggestions would be breaking changes for SemVer, requiring a new major version. If there's any interest in this, I would be more than happy to work on a RFC/PR.

GiteaMirror commented

2026-06-17 05:21:20 -05:00

@ljharb commented on GitHub (Feb 18, 2022):

How are security fixes different from any other bug fixes?

@ljharb commented on GitHub (Feb 18, 2022): How are security fixes different from any other bug fixes?

GiteaMirror commented

2026-06-17 05:21:20 -05:00

@mkungla commented on GitHub (Feb 18, 2022):

I fully agree here with @ljharb,

How are security fixes different from any other bug fixes?

THEY ARE NOT. security fixes are clearly <patch> . I understand that intention is to skip some of the internal Q&A and to push security patches out quicker than regular patches which may rather introduce security vulnerability. However I feel this proposed approach as it is presented here is bad by the design as similar like some while ago some proposal for "version forking".

I find that if to use some Quality Assurance exceptions for security patches then these still SHOULD live in <build> meta, but minimal MUST be always incremented .

e.g. project specific version interpretation to simplify QA

1.0.0
1.0.1 # QA passed 
# 1.0.2+security  does not require full QA since project states that version  
# `+security` meta is only used when changes in this release are related 
# e.g for specific CWE and nothing else
1.0.2+security 
1.0.3+security # does not require full QA since ...
1.0.4 # requires QA

1.0.0
1.0.1 # QA passed 
1.0.2 # QA in progress 
# 1.0.3+security  requires full QA since there is patch between  security patch 
# and last accepted version which has not passed QA.
1.0.3+security

do work around blocking 1.0.2 in this example could be using principals of LTS

when you have <minor> which has one or more <patch> with <build> == security then release new <minor> as quickly as possible so that if you want to provide security patches to 1.0.x then you can easily do so keep as many 1.0.x+security patches as you wish.

1.1.0+LTS # QA passed
1.2.0 # current tip

# you want to release security patch for `1.1.0` without forcing upgrade to `1.2.0` 
# then just release <patch> for `1.1.0` 
1.1.1+security

@RichiH perhaps you can elaborate why such model would not satisfy and you think that moving project specific <build> info into general purpose additional <subpatch> is good idea?

Specially since security patches can be it self sometimes require <minor> or even <major> update.

@mkungla commented on GitHub (Feb 18, 2022): I fully agree here with @ljharb, > How are security fixes different from any other bug fixes? THEY ARE NOT. security fixes are clearly `<patch>` . I understand that intention is to skip some of the *internal Q&A* and to push security patches out quicker than regular patches which may rather introduce security vulnerability. However I feel this proposed approach as it is presented here is bad by the design as similar like some while ago some proposal for "version forking". I find that if to use some Quality Assurance exceptions for security patches then these still SHOULD live in `<build>` meta, but minimal <patch> MUST be always incremented . **e.g. project specific version interpretation to simplify QA** ```sh 1.0.0 1.0.1 # QA passed # 1.0.2+security does not require full QA since project states that version # `+security` meta is only used when changes in this release are related # e.g for specific CWE and nothing else 1.0.2+security 1.0.3+security # does not require full QA since ... 1.0.4 # requires QA ``` ```sh 1.0.0 1.0.1 # QA passed 1.0.2 # QA in progress # 1.0.3+security requires full QA since there is patch between security patch # and last accepted version which has not passed QA. 1.0.3+security ``` **do work around blocking `1.0.2` in this example could be using principals of LTS** when you have `<minor>` which has one or more `<patch>` with `<build> == security ` then release new `<minor>` as quickly as possible so that if you want to provide security patches to `1.0.x` then you can easily do so keep as many `1.0.x+security` patches as you wish. ```sh 1.1.0+LTS # QA passed 1.2.0 # current tip # you want to release security patch for `1.1.0` without forcing upgrade to `1.2.0` # then just release <patch> for `1.1.0` 1.1.1+security ``` @[RichiH](https://github.com/RichiH) perhaps you can elaborate why such model would not satisfy and you think that moving project specific `<build>` info into general purpose additional `<subpatch>` is good idea? Specially since security patches can be it self sometimes require `<minor>` or even `<major>` update.

GiteaMirror commented

2026-06-17 05:21:21 -05:00

@RichiH commented on GitHub (Feb 18, 2022):

@kunkel246 this looks like spam. Could you delete it, please?

@ljharb in the general case: They allow non-intended behavior to be triggered by third parties with some level of reliability. In this specific case, we want to be able to release normal patch releases without leaking the existence of a currently-private release, nor to block development workflow. If done right, their fix releases contain nothing but security-relevant changes.

@mkungla as per specification, build information MUST NOT be used to determine version precedence. As such, it is impossible to use it for any resilient upgrade processes.
Cases in which <minor> or even <major> need to be bumped are possible, but out of scope for the use cases described above.
In generalized form, <subpatch> (or similar) would have the intuitively correct semantic meaning: A way to improve upon a <patch> version.

@RichiH commented on GitHub (Feb 18, 2022): @kunkel246 this looks like spam. Could you delete it, please? @ljharb in the general case: They allow non-intended behavior to be triggered by third parties with some level of reliability. In this specific case, we want to be able to release normal patch releases without leaking the existence of a currently-private release, nor to block development workflow. If done right, their fix releases contain nothing but security-relevant changes. @mkungla as per specification, build information MUST NOT be used to determine version precedence. As such, it is impossible to use it for any resilient upgrade processes. Cases in which `<minor>` or even `<major>` need to be bumped are possible, but out of scope for the use cases described above. In generalized form, `<subpatch>` (or similar) would have the intuitively correct semantic meaning: A way to improve upon a `<patch>` version.

GiteaMirror commented

2026-06-17 05:21:23 -05:00

@ljharb commented on GitHub (Feb 18, 2022):

@RichiH bugs are all unintended behavior, whether it’s something that gets a security engineer excited or not. That’s the definition of bug.

@ljharb commented on GitHub (Feb 18, 2022): @RichiH bugs are all unintended behavior, whether it’s something that gets a security engineer excited or not. That’s the definition of bug.

GiteaMirror commented

2026-06-17 05:21:23 -05:00

@RichiH commented on GitHub (Feb 18, 2022):

@ljharb Again, they allow non-intended behavior to be triggered by third parties with some level of reliability. I do not wish to replay the discussions around this topic from LKML and elsewhere, though. There are two distinct and incompatible schools of thought around this topic.

While security releases are my initial motivation, the generic solution proposed is not limited to security releases.

@RichiH commented on GitHub (Feb 18, 2022): @ljharb Again, they allow non-intended behavior to be **triggered by third parties with some level of reliability**. I do not wish to replay the discussions around this topic from LKML and elsewhere, though. There are two distinct and incompatible schools of thought around this topic. While security releases are my initial motivation, the generic solution proposed is not limited to security releases.

GiteaMirror commented

2026-06-17 05:21:24 -05:00

@mkungla commented on GitHub (Feb 18, 2022):

@RichiH thats the whole point build information MUST NOT be used to determine version precedence that's why in example I gave you it is possible to follow current specification.

1.1.0+LTS # QA passed
1.2.0 # current tip

# you want to release security patch for `1.1.0` without forcing upgrade to `1.2.0` 
# then just release <patch> for `1.1.0` 
1.1.1+security

regardless is it security patch or not, it still SHOULD increment at least the patch number.
You can use <build> e.g. 1.1.1+security in scope of your project to decide your QA rules and NOT to determine version precedence. This totally valid use of semver since using

So this is invalid:

1.1.0
1.1.0+security

And following is totally fine if you have users with constraint >= 1.1.0 <= 1.2.0, they will receive your security patch 1.1.2+security and are not forced to upgrade to 1.2.0. NOTE that +security build info in this case you are just specifying release policy what you promise your project to follow. Your user may or may not opt in to loosen QA in cases where <patch>+security is released semantically next version they have approved.

1.1.0
1.1.2+security
1.2.0
1.1.3+security

To add additional scope what you ask to spec is impossible since we are generally still speaking about <patch> and there is no way now or in the future to universally determine where is the line between <patch> and your <patch>.<subpatch>

@mkungla commented on GitHub (Feb 18, 2022): @[RichiH](https://github.com/RichiH) thats the whole point `build information MUST NOT be used to determine version precedence` that's why in example I gave you it is possible to follow current specification. > 1.1.0+LTS # QA passed > 1.2.0 # current tip > > # you want to release security patch for `1.1.0` without forcing upgrade to `1.2.0` > # then just release <patch> for `1.1.0` > 1.1.1+security regardless is it security patch or not, it still SHOULD increment at least the patch number. You can use `<build>` e.g. `1.1.1+security` in scope of your project to decide your `QA` rules and NOT to determine version precedence. This totally valid use of semver since using So this is invalid: - 1.1.0 - 1.1.0+security And following is totally fine if you have users with constraint `>= 1.1.0 <= 1.2.0`, they will receive your security patch `1.1.2+security` and are not forced to upgrade to `1.2.0`. NOTE that `+security` build info in this case you are just specifying release policy what you promise your project to follow. Your user may or may not opt in to loosen QA in cases where `<patch>+security` is released semantically next version they have approved. - 1.1.0 - 1.1.2+security - 1.2.0 - 1.1.3+security To add additional scope what you ask to spec is impossible since we are generally still speaking about `<patch>` and there is no way now or in the future to universally determine where is the line between `<patch>` and your `<patch>.<subpatch>`

GiteaMirror commented

2026-06-17 05:21:25 -05:00

@ljharb commented on GitHub (Feb 18, 2022):

In semver, there’s only one school of thought - a change that’s not breaking and isn’t adding new behavior is patch. Whether something is arbitrarily decided to be a security issue or not (and it is very much not objective) is irrelevant in semver.

@ljharb commented on GitHub (Feb 18, 2022): In semver, there’s only one school of thought - a change that’s not breaking and isn’t adding new behavior is patch. Whether something is arbitrarily decided to be a security issue or not (and it is very much not objective) is irrelevant in semver.

GiteaMirror commented

2026-06-17 05:21:26 -05:00

@RichiH commented on GitHub (Feb 18, 2022):

@mkungla In this usage, <build> is a no-op. The actual functionality is coming through <patch> only, which was my point. Signalling what the intention of a build is is largely irrelevant for this use case. Determining that it's a higher version is the desired behavior.

@ljharb This is a correct description of current behavior, agreed. I would prefer to stop this cyclic discussion while still awaiting wider feedback.

If yours is an authoritative statement from the SemVer project as a whole, please let me know so I can close the issue.

@RichiH commented on GitHub (Feb 18, 2022): @mkungla In this usage, `<build>` is a no-op. The actual functionality is coming through `<patch>` only, which was my point. Signalling what the intention of a build is is largely irrelevant for this use case. Determining that it's a higher version is the desired behavior. @ljharb This is a correct description of current behavior, agreed. I would prefer to stop this cyclic discussion while still awaiting wider feedback. If yours is an authoritative statement from the SemVer project as a whole, please let me know so I can close the issue.

GiteaMirror commented

2026-06-17 05:21:27 -05:00

@jwdonahue commented on GitHub (May 3, 2022):

I think I linked a bunch of the "expand the version triple to..." class of threads. It's a perennial discussion that never goes anywhere. There have been at least a half dozen PR's issued in the past that languished years before finally being closed by an ambitious maintainer. I can tell you from experience that anything that adds or removes numeric fields from version core is not going to happen.

Any such changes would require a major version bump of the spec and the maintainers are all about stability. There's also the problem of disambiguating between 2.0.0 and any 3.0.0 syntax such that correct semantics can be applied. Fact is there's a lot of tools out there that have 4 integer version fields already and none of them need the SemVer stamp of approval to be useful.

@jwdonahue commented on GitHub (May 3, 2022): I think I linked a bunch of the "expand the version triple to..." class of threads. It's a perennial discussion that never goes anywhere. There have been at least a half dozen PR's issued in the past that languished years before finally being closed by an ambitious maintainer. I can tell you from experience that anything that adds or removes numeric fields from version core is not going to happen. Any such changes would require a major version bump of the spec and the maintainers are all about stability. There's also the problem of disambiguating between 2.0.0 and any 3.0.0 syntax such that correct semantics can be applied. Fact is there's a lot of tools out there that have 4 integer version fields already and none of them need the SemVer stamp of approval to be useful.

GiteaMirror commented

2026-06-17 05:21:27 -05:00

@jwdonahue commented on GitHub (May 3, 2022):

[GH-ISSUE #803] Support for more granular releases than <patch> level #6519

[GH-ISSUE #803] Support for more granular releases than `<patch>` level #6519