I use semver spec 2.0.
What should be the version number increments when
the current version 2.0.0-beta.1 is has already been distributed.
Now, a bug is fixed.
If version 2.0.1-beta.1 or 2.0.0-beta.2 be better?
Asked
Active
Viewed 735 times
0
Manuel
- 125
- 3
- 7
-
is the bug backwards compatible? – Peter Ritchie Jan 29 '14 at 19:20
-
Ok, it's backwards compatible – Manuel Jan 30 '14 at 00:23
1 Answers
1
If the bug fix is backwards compatible you should increment the PATCH version (e.g. 2.0.0-beta.1->2.0.1-beta.1). If the bug fix is not backwards compatible with the last minor/major version then you should increment the MINOR or MAJOR version, depending on what isn't backwards compatible. Which, I would assume, mean a whole new beta. E.g. 2.0.1-beta.1->2.1.0-beta.1 or 2.0.1-beta.1->3.0.0-beta.1.
If it's a non-backward bug fix from a the previous beta, then it's really up do you to decide what level of support you want in a beta.
Peter Ritchie
- 35,463
- 9
- 80
- 98
-
You mean, the beta level is freeze and only the major, minor and patch version is increment? And when should i increment the beta.1 to beta.2? – Manuel Jan 30 '14 at 00:24
-
With semver there's a lot of leeway with beta. You can roughly follow the MAJOR/MINOR rules and assume that if you make a breaking change to a beta 1 in a new build that it's just beta 2 because you don't really need to support beta 2. To look at it much more deeply means you'd need another layer of M/P versioning (e.g. M1.m1.p.b.M2.m2.) Generally, when you release a beta you're not making an semantic guarantees about backward compatibility between different beta versions of the same minor version. e.g. if you introduce a new feature in beta 1 and break it in b1, you can just call it b2. – Peter Ritchie Jan 30 '14 at 02:12