releasing alpha to beta to production with SemVer

Question

My understanding of the SemVer release cycle is as follows:

1. My first release is going to be 0.1.0-alpha.1
2. I may make a few tweaks and re-release at 0.1.0-alpha.2 (repeat as needed)
3. When ready, I release 0.1.0-beta.1
4. I may make a few tweaks and re-release at 0.1.0-alpha.2 (repeat as needed)
5. When ready, I release into production: 1.0.0

Am I correct in keeping the same minor version throughout? The SemVer website hints at this (section 11, link below): "Example: 1.0.0-alpha < 1.0.0". This suggests that two versions of "1.0.0" can co-exist.

Or should I increment the minor/patch for each release, e.g.:

• 0.1.0-alpha.1

• 0.1.1-alpha.1

• 0.1.2-beta.1

• 0.2.0-beta.1

• 1.0.0

If that's the case, I don't get how to use the alpha.x or beta.x increments?

Ref: https://semver.org/

Answer 1

The SemVer spec gives you a lot of flexibility. Nothing in the spec precludes your using the numbered scenario you describe in your original post. Your alternative suggestion is also valid, as far as SemVer is concerned. Both scenarios start out with the 0.y.z form, which is meant to be used for initial development leading up to 1.0.0. Any applied prerelease tags are mostly sugar, though they will factor into the sort order (1.0.0 > 0.1.0 > 0.1.0-otherPreleaseTag > 0.1.0-anyPreleaseTag).

4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

These are all legal SemVer version histories:

H1

0.1.0
0.1.1
0.2.0
0.2.1
1.0.0

H2

0.1.0
0.1.1
0.2.0
0.2.1
1.0.0-alpha.1
1.0.0-alpha.2
1.0.0-beta.1
1.0.0-beta.2
1.0.0

H3

0.1.0
0.1.1
0.2.0
0.2.1
1.0.0-alpha
1.0.1-alpha
1.0.2-beta
1.0.3-beta
1.0.3

SemVer supports an endless variety of develop/release patterns. The key is that the spec applies the same exact semantic meaning to all prerelease tags.

9. ...A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.

You just need to focus on the precedence rules, which define the sort order that is applied with deciding a match to consumer intent, from the available versions.