development process – Which SemVer version to use between releases?

I’m working on a project that uses Semantic Versioning. The commit history can be generalized as:

enter image description here

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.z will be the next release, but we are currently developing it.
  • That reserves x.y.z for the one commit that is a release.
  • That directly after a release, updates the source code to use a new x.y.z-dev version.

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, 1.0.0 to 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 2.0.0-dev.

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.