[GH-ISSUE #709] Support multi-version specifiers (a.k.a. post release/packaging markers) #5600

New Issue

GiteaMirror · 2026-06-15T12:06:41-05:00

GiteaMirror commented

2026-06-15 12:06:41 -05:00

Originally created by @yajo on GitHub (Jun 9, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/709

Hello. I like semver, but I miss something that marks a post-release.

Why? Well, there are some projects that are just based on an upstream project, and their versions depend on upstream's. One simple example is almost any package on any linux distro. Examples:

Debian/Ubuntu packages. A package can be 1.2.3-1ubuntu3, meaning "upstream version 1.2.3, debian version 1, ubuntu version 3".
k3s. A release can be 1.18.6+k3s3 meaning "Kubernetes version 1.18.6 with 3rd k3s version".
I maintain a few docker images of some projects. I'd like a way to do something similar to k3s, but being really semantic.

As you can see, the k3s case is abusing the build metadata feature to actually produce a new version with higher precedence, while semver 2.0.0 declares that build metadata should be ignored for precedence.

IMHO this is a valid use case.

My proposal is that we pick up a character (I suggest &, but / or | or : should be good too) to separate post-release markers. The format for the above package example would look like:

1.2.3&debian.1.0.0&ubuntu.3.0.0

For k3s:

1.18.6&k3s.3.0.0

Or, for a more complete example:

1.2.3-alpha1+build1234&debian.1.2.3-beta4+202019102somerandombuilddata&ubuntu.3.0.0-rc1+ubuntumetabuilddatalol

Well, that's ugly, but you get the point:

Semver stays as it is.
But, when & is encountered, it is followed by an alphanumeric identifier that marks the section.
Then, after a ., the following is another valid semver specifier.
When computing precedence, always prior sections are more important; following sections are sorted by appearance order.
If a version lacks a post section, and it needs one to be compared to another version, it's equivalent to &a.0.0.0.

For example, from lower to higher:

1.2.3
1.2.3&debian.1.0.1-alpha.1&ubuntu.3.0.0
1.2.3&debian.1.0.0
1.2.3&debian.1.0.0&ubuntu.1.0.0
1.2.3&ubuntu.0.0.1 (because `debian` > `ubuntu`)

Originally created by @yajo on GitHub (Jun 9, 2021). Original GitHub issue: https://github.com/semver/semver/issues/709 Hello. I like semver, but I miss something that marks a post-release. Why? Well, there are some projects that are just based on an upstream project, and their versions depend on upstream's. One simple example is almost any package on any linux distro. Examples: 1. [Debian/Ubuntu packages](https://serverfault.com/a/604549/125479). A package can be `1.2.3-1ubuntu3`, meaning "upstream version 1.2.3, debian version 1, ubuntu version 3". 2. [k3s](https://github.com/k3s-io/k3s/blob/f6cec4e75d0bd298988000cc313b6e9685fb0acc/README.md#release-cadence). A release can be `1.18.6+k3s3` meaning "Kubernetes version 1.18.6 with 3rd k3s version". 3. I maintain a few docker images of some projects. I'd like a way to do something similar to k3s, but being really semantic. As you can see, the k3s case is abusing the build metadata feature to actually produce a new version with higher precedence, while semver 2.0.0 declares that build metadata should be ignored for precedence. IMHO this is a valid use case. My proposal is that we pick up a character (I suggest `&`, but `/` or `|` or `:` should be good too) to separate post-release markers. The format for the above package example would look like: 1.2.3&debian.1.0.0&ubuntu.3.0.0 For k3s: 1.18.6&k3s.3.0.0 Or, for a more complete example: 1.2.3-alpha1+build1234&debian.1.2.3-beta4+202019102somerandombuilddata&ubuntu.3.0.0-rc1+ubuntumetabuilddatalol Well, that's ugly, but you get the point: 1. Semver stays as it is. 2. But, when `&` is encountered, it is followed by an alphanumeric identifier that marks the section. 3. Then, after a `.`, the following is another valid semver specifier. 4. When computing precedence, always prior sections are more important; following sections are sorted by appearance order. 5. If a version lacks a post section, and it needs one to be compared to another version, it's equivalent to `&a.0.0.0`. For example, from lower to higher: ``` 1.2.3 1.2.3&debian.1.0.1-alpha.1&ubuntu.3.0.0 1.2.3&debian.1.0.0 1.2.3&debian.1.0.0&ubuntu.1.0.0 1.2.3&ubuntu.0.0.1 (because `debian` > `ubuntu`) ```

GiteaMirror closed this issue

2026-06-15 12:06:41 -05:00

GiteaMirror commented

2026-06-15 12:06:42 -05:00

@ljharb commented on GitHub (Jun 9, 2021):

It sounds like you want a separate versioning system. This isn't what semver is - there's only one version. Things should not be packaged by "not the software author" - the versioned release IS the ultimate and only package that matters.

@ljharb commented on GitHub (Jun 9, 2021): It sounds like you want a separate versioning system. This isn't what semver is - there's only one version. Things should not *be* packaged by "not the software author" - the versioned release IS the ultimate and only package that matters.

GiteaMirror commented

2026-06-15 12:06:42 -05:00

@alexandrtovmach commented on GitHub (Jun 14, 2021):

SemVer spec is something stable and strict, and if you want to change it, please create fork or start another project

closing in favor of https://github.com/semver/semver/issues/703#issuecomment-841420754

@alexandrtovmach commented on GitHub (Jun 14, 2021): >SemVer spec is something stable and strict, and if you want to change it, please create fork or start another project closing in favor of https://github.com/semver/semver/issues/703#issuecomment-841420754

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#5600