[GH-ISSUE #701] [Question] Semver ordering for pre-release and post-release with incrementing build number #6464

New Issue

GiteaMirror · 2026-06-17T05:16:24-05:00

GiteaMirror commented

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

Originally created by @Zephilinox on GitHub (May 13, 2021).
Original GitHub issue: https://github.com/semver/semver/issues/701

given a pre-release version of 1.0.0-beta.1 we would like additional versioning so that newer internal builds of our software that we haven't released can still be ordered.

currently this is done by counting the number of commits since the last release, e.g. 1.0.0-beta.1 would be 1.0.0-beta.1.27 if there have been 27 commits since the release.

once we've released and the version is now 1.0.0, the next internal build would be 1.0.0.1 which is clearly invalid. we could do 1.0.0-1 but as -1 is a pre-release, 1.0.0 is considered to be newer

we're aware of the build metadata and would like to use that for e.g. timestamps or git hashes, but being able to order each new internal release is really helpful for testing internal packages as dependencies of other internal packages, so encoding the commits-since-release in the build metadata part of semver doesn't help us.

https://semvercompare.azurewebsites.net/?version=1.0.0-beta.1&version=1.0.1&version=1.0.0-27&version=1.0.0-beta.1.27&version=1.0.0

is there a good solution to this problem?

Originally created by @Zephilinox on GitHub (May 13, 2021). Original GitHub issue: https://github.com/semver/semver/issues/701 given a pre-release version of `1.0.0-beta.1` we would like additional versioning so that newer internal builds of our software that we haven't released can still be ordered. currently this is done by counting the number of commits since the last release, e.g. `1.0.0-beta.1` would be `1.0.0-beta.1.27` if there have been 27 commits since the release. once we've released and the version is now `1.0.0`, the next internal build would be `1.0.0.1` which is clearly invalid. we could do `1.0.0-1` but as `-1` is a pre-release, `1.0.0` is considered to be newer we're aware of the build metadata and would like to use that for e.g. timestamps or git hashes, but being able to order each new internal release is really helpful for testing internal packages as dependencies of other internal packages, so encoding the commits-since-release in the build metadata part of semver doesn't help us. https://semvercompare.azurewebsites.net/?version=1.0.0-beta.1&version=1.0.1&version=1.0.0-27&version=1.0.0-beta.1.27&version=1.0.0 is there a good solution to this problem?

GiteaMirror added the question label 2026-06-17 05:16:24 -05:00

GiteaMirror closed this issue

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

GiteaMirror commented

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

@ljharb commented on GitHub (May 13, 2021):

Why would the next internal build after 1.0.0 be anything but 1.0.1-beta.0? (assuming you want “beta” as the prerelease name, and assuming the changes in it are semver-patch)

@ljharb commented on GitHub (May 13, 2021): Why would the next internal build after 1.0.0 be anything but 1.0.1-beta.0? (assuming you want “beta” as the prerelease name, and assuming the changes in it are semver-patch)

GiteaMirror commented

2026-06-17 05:16:28 -05:00

@Zephilinox commented on GitHub (May 13, 2021):

It's hard to know what version the next release is. It could be 1.0.1, but it could also be 1.1.0

That's not a decision we can easily make after every release (and wouldn't want to do so manually)

@Zephilinox commented on GitHub (May 13, 2021): It's hard to know what version the next release is. It could be 1.0.1, but it could also be 1.1.0 That's not a decision we can easily make after every release (and wouldn't want to do so manually)

GiteaMirror commented

2026-06-17 05:16:28 -05:00

@Zephilinox commented on GitHub (May 13, 2021):

Maybe that's the only option though, and we just need to change our mentality on having a beta for a release version that may never exist

@Zephilinox commented on GitHub (May 13, 2021): Maybe that's the only option though, and we just need to change our mentality on having a beta for a release version that may never exist

GiteaMirror commented

2026-06-17 05:16:28 -05:00

@ljharb commented on GitHub (May 13, 2021):

@Zephilinox the way prereleases are supposed to work is indeed that you decide with each one what the version would be if you published it normally. That means you might have v1.0.0, v1.0.1-beta.0, v1.0.1-beta.1, v1.1.0-beta.0, v1.1.0, etc, and that's ok.

@ljharb commented on GitHub (May 13, 2021): @Zephilinox the way prereleases are supposed to work is indeed that you decide with each one what the version would be if you published it normally. That means you might have v1.0.0, v1.0.1-beta.0, v1.0.1-beta.1, v1.1.0-beta.0, v1.1.0, etc, and that's ok.

GiteaMirror commented

2026-06-17 05:16:29 -05:00

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

@Zephilinox is it helpful?

@alexandrtovmach commented on GitHub (Jun 14, 2021): @Zephilinox is it helpful?

GiteaMirror commented

2026-06-17 05:16:30 -05:00

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

kinda :b

it's good to know we didn't miss an alternative method, but it's a bit of a pain to programatically increase the minor version after a release when compared to what we're currently doing, which is appending something to the end of the release.

It adds some confusion too, people do need our internal development builds and that results in them seeing a version that we might never actually release.

it's not a big deal, just one of those things :)

happy to close the ticket though, thanks for the help :)

@Zephilinox commented on GitHub (Jun 14, 2021): kinda :b it's good to know we didn't miss an alternative method, but it's a bit of a pain to programatically increase the minor version after a release when compared to what we're currently doing, which is appending something to the end of the release. It adds some confusion too, people do need our internal development builds and that results in them seeing a version that we might never actually release. it's not a big deal, just one of those things :) happy to close the ticket though, thanks for the help :)

GiteaMirror commented

2026-06-17 05:16:30 -05:00

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

Ricardo Heath wrote:"It adds some confusion too, people do need our internal development builds and that results in them seeing a version that we might never actually release."This is not meant as any new 'ticket' or anything like that, but rather some food for thought maybe. I do find it semantically very contradictory even just to say that (presumably) external people need an internal development build for anything at all. It cannot be called internal, then, can it?It would be more in line with logic and semantic reasoning to call these intermediate builds (released yet not 'actually' released either?) something like beta, alpha, unstable, intermediate, preview, experimental, trial, testbuild, nightly or whatever reflects their purpose or use.-+-Ben-+-
null

@bhetland commented on GitHub (Jun 14, 2021): Ricardo Heath wrote:"It adds some confusion too, people do need our internal development builds and that results in them seeing a version that we might never actually release."This is not meant as any new 'ticket' or anything like that, but rather some food for thought maybe. I do find it semantically very contradictory even just to say that (presumably) external people need an _internal_ development build for anything at all. It cannot be called internal, then, can it?It would be more in line with logic and semantic reasoning to call these intermediate builds (released yet not 'actually' released either?) something like beta, alpha, unstable, intermediate, preview, experimental, trial, testbuild, nightly or whatever reflects their purpose or use.-+-Ben-+- null

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6464