A master branch in git following semantic versioning has released below versions in its lifecycle till date.
1.0.0 -> 1.0.1 -> 1.1.0 -> 1.2.0
A hotfix branch is cutoff named hotfix\1.0.0 for a bug fix/compatible extension, which will necessitate a version released as either 1.0.1 or 1.1.0. But both these version numbers are already released at the master Level. What is the best strategy to use to avoid such conflicts with versions.
Semantic Versioning 2.0.0 has this part at the beginning:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backwards compatible manner
- PATCH version when you make backwards compatible bug fixes
So a hotfix would go into the patch version as it does not add any feature but fixes a bug.
If you want to avoid situations where you have a patch planned and want to publish a hotfix before that patch release and you cannot or don't want to change the version of the planned release, you could add further semantic meanings to the patch version number itself.
You could for example say that any regular patch version is even and hotfix patch release versions are odd.
So if you are at 1.0.0 and 1.0.2 is planned then you can have a 1.0.1-hotfix.1
As PATCH denotes bug fixes and must not break compatibility (except if the user relied on a bug - which should not be your problem) the user of the library should always update to the latest PATCH version. So it never should happen that a user needs a 0.0.1 hotfix in case a e.g. 0.0.4 is already available, either the bug is already fixed in 0.0.4 or 0.0.4 has to be also fixed resulting in a new PATCH version newer then 0.0.4.
There is also a discussion about that topic on GitHub: semver#241