[GH-ISSUE #841] Question: Prerelease and release number must be the same for same code? #3263

New Issue

GiteaMirror · 2026-04-25T17:36:23-05:00

GiteaMirror commented

2026-04-25 17:36:23 -05:00

Originally created by @migius on GitHub (May 30, 2022).
Original GitHub issue: https://github.com/semver/semver/issues/841

In a project I use gitflow and semver in this way:

feature branches > X.Y.Z-alpha
develop branch > X.Y.Z-beta
main > X.Y.Z

Of course the prereleases has much more new versions that the develop and the main.

With this situation:

1.0.0
1.0.1-beta, 1.0.2-beta
1.0.1-alpha, 1.0.2-alpha, ... 1.0.12-alpha

if I merge 1.0.12-alpha on develop ewhat is the right new beta version?

create the 1.0.12-beta (but no version exists between 2-beta and 12 beta)
create the 1.0.3-beta (that corrispond to the 12-alpha)

same question for "release" version.

Originally created by @migius on GitHub (May 30, 2022). Original GitHub issue: https://github.com/semver/semver/issues/841 In a project I use gitflow and semver in this way: * feature branches > X.Y.Z-alpha * develop branch > X.Y.Z-beta * main > X.Y.Z Of course the prereleases has much more new versions that the develop and the main. With this situation: 1.0.0 1.0.1-beta, 1.0.2-beta 1.0.1-alpha, 1.0.2-alpha, ... 1.0.12-alpha if I merge 1.0.12-alpha on develop ewhat is the right new beta version? * create the 1.0.12-beta (but no version exists between 2-beta and 12 beta) * create the 1.0.3-beta (that corrispond to the 12-alpha) same question for "release" version.

GiteaMirror commented

2026-04-25 17:36:24 -05:00

@nskobelevs commented on GitHub (May 30, 2022):

I think you're misusing semvar in this situation. It's designed to version packages that are released for use whether that be npm, cargo or any other form of release.

In general, git branches aren't releases of the package because they don't represent a specific version of the code but a series of changes. So if you have a branch 1.0.1-alpha then you're problem is that you don't know what actual version you are referring to. Is it branch 1.0.1-alpha right now, 2 weeks ago, when the first commit was made? It doesn't concretely specify which version of the software you're using because it refers to a whole branch. A solution to this is to semver every commit as a pre-release (careful not to use commit id) but that's probably overkill.

In general, I would recommend that only master have a version (and a tag on a specific commit to specify that version) as usually in spirit with git flow.
Likewise, git flow has the release branch when preparing a release. Since this branch is usually for bug-fixes only, you could use increment the patch version for these commits but overall, it doesn't make sense for a branch itself to use semver.

@nskobelevs commented on GitHub (May 30, 2022): I think you're misusing semvar in this situation. It's designed to version packages that are released for use whether that be npm, cargo or any other form of release. In general, git branches aren't releases of the package because they don't represent a specific version of the code but a series of changes. So if you have a branch `1.0.1-alpha` then you're problem is that you don't know what actual version you are referring to. Is it branch `1.0.1-alpha` right now, 2 weeks ago, when the first commit was made? It doesn't concretely specify which version of the software you're using because it refers to a whole branch. A solution to this is to semver every commit as a pre-release (careful not to use commit id) but that's probably overkill. In general, I would recommend that only master have a version (and a tag on a specific commit to specify that version) as usually in spirit with git flow. Likewise, git flow has the release branch when preparing a release. Since this branch is usually for bug-fixes only, you could use increment the patch version for these commits but overall, it doesn't make sense for a branch itself to use semver.

GiteaMirror commented

2026-04-25 17:36:24 -05:00

@arbazshiekh31 commented on GitHub (Aug 25, 2022):

@841

@arbazshiekh31 commented on GitHub (Aug 25, 2022): @841

GiteaMirror commented

2026-04-25 17:36:25 -05:00

@jwdonahue commented on GitHub (Sep 16, 2022):

Version tags on git content hashes are redundant and don't scale well. The purpose of release branches however is to provide an easy point to go back to when you need to roll a fix across multiple releases. You don't generally create them for minor, patch or prerelease changes, you create them when you must support several major versions at one time, so the nomenclature should be more like v1, v2, v3 (non semver tags) for your release branches.

In other words, you don't apply SemVer to your source. Instead you go back and tag the content hash that produced whatever bits you finally released, which is something that happens after the build is completed and asynchronous to any source code changes taking place.

@jwdonahue commented on GitHub (Sep 16, 2022): Version tags on git content hashes are redundant and don't scale well. The purpose of release branches however is to provide an easy point to go back to when you need to roll a fix across multiple releases. You don't generally create them for minor, patch or prerelease changes, you create them when you must support several major versions at one time, so the nomenclature should be more like v1, v2, v3 (non semver tags) for your release branches. In other words, you don't apply SemVer to your source. Instead you go back and tag the content hash that produced whatever bits you finally released, which is something that happens after the build is completed and asynchronous to any source code changes taking place.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#3263