3

How should versions be bumped during development between two major versions? For example let say I have version 1.5.0 and my target is to release new major version that will be incompatible with major version 1.

As soon as I start developing and making changes, those changes will be backwards incompatible, so by following semantic versioning, should I already bump it to 2.0.0? But development is in progress and code is still unstable.

Or should I bump like any other compatible feature -> 1.6.0, 1.6.1, 1.7.0 etc. and when new major version is ready, just bump to 2.0.0?

Should it be suffixed with something like 2.0.0-alpha and then reset 2.0.0, once it stable? Or bump 1.5.0-alpha (though does not look right).

P.S. When starting from scratch, it makes sense to start with 0.1.0, because there is no major version yet, but when there is one, it gets tricky..:)

Improve this question
4
  • You version releases.
    – jonrsharpe
    Mar 29, 2019 at 8:04
  • @jonrsharpe I know, what else could I release? But if my release is still not stable, what version should it be?
    – Andrius
    Mar 29, 2019 at 8:05
  • You also version "release candidates"
    – Laiv
    Mar 29, 2019 at 8:06
  • What do you mean "what version should it be"? That question doesn't make sense, because you version what you release (alpha, beta, rc or final - these are all being released). In between, it doesn't have a version. In the codebase it'll stay at 1.5.0 during those commits.
    – jonrsharpe
    Mar 29, 2019 at 8:09

1 Answer 1

Reset to default
5

As soon as I start developing and making changes, those changes will be backwards incompatible, so by following semantic versioning, should I already bump it to 2.0.0? But development is in progress and code is still unstable.

You answer your own question here: "development is in progress and code is still unstable", so the code isn't ready for release. Semantic versioning applies to releases, not commits etc. So there is no issue. Your last release remains 1.5.0 until you are ready to release the next version, which is 2.0.0.

Of course, whilst you are developing, you may wish to release early, pre-release versions. Then you append that fact to the version number, eg 2.0.0-alpha001, 2.0.0-rc3 etc as required.

Improve this answer
3
  • So I guess then, first release (if its not stable release), could be 2.0.0-rc or 2.0.0-alpha or whatever? I just got confused by the fact that you start with 0.1.0 and then only bump major version once it is stable (but you still bump unstable releases for 0 major version)
    – Andrius
    Mar 29, 2019 at 8:08
  • With CI in use, for any commit can be an internal "release" which should be named somehow and considered by other modules.
    – max630
    Mar 29, 2019 at 8:09
  • @Andrius, that is correct.v0 is a special case. After v1, pre-releases rely on appending some sort of annotation to the version to reflect that it's a pre-release. I've updated the answer to reflect that.
    – David Arno
    Mar 29, 2019 at 8:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.