Question: Prerelease and release number must be the same for same code?

[migius]

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.

[nskobelevs]

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.

[jwdonahue]

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.