I’m working on a project that uses Semantic Versioning. The commit history can be generalized as:
Also, the current version is present in source code (so that the software can use it for various purposes).
I’d like to start implementing a process that I’ve been seeing around:
- That has development commits contain a version such as
x.y.z-dev. The idea is that
x.y.zwill be the next release, but we are currently developing it.
- That reserves
x.y.zfor the one commit that is a release.
- That directly after a release, updates the source code to use a new
This allows the software as seen on development commits to not erroneously suggest that it represents a release version.
The issue I’m running into is knowing which version to increment to after a release. Semantic Versioning has requirements for what kinds of changes can be found in a new version. For example,
2.0.0 indicates a backwards-incompatible change has been made to some interface. But, directly after a release (when the version is incremented to a new
-dev version), it’s hard to say what kinds of changes will be included in the future for the next release.
For example, if we just released
1.2.3, incremented to
1.2.4-dev, and then introduce a backwards-incompatible change,
1.2.4-dev is now invalid and should be
Should I just do another increment to the next
-dev major version during the development cycle when we notice that such a change has occurred? It seems iffy that commits would then exist with a version that would never be released.