-1

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.

Nitesh
  • 31
  • 4
  • 1
    You have different options: **1.** dedicate the `patch` part to hotfix **2.** use the `-` for hotfix version information. `1.0.0-hf1`, `1.0.0-hf2`, or any other format. **3.** Use the `+` for the build information. – t.niese Jan 27 '23 at 12:35
  • Option 1 will mean bug fixes on master version will not be properly catered in the semantic version. It gets treated as a new feature addition. Option 2 is making use of pre release identifier. But having that as 1.0.0-hf1 would mean 1.0.0-hf1 being treated as a lesser version than 1.0.0, but actually it is the other way around. – Nitesh Jan 27 '23 at 13:05

1 Answers1

1

Semantic Versioning 2.0.0 has this part at the beginning:

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes
  2. MINOR version when you add functionality in a backwards compatible manner
  3. 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

t.niese
  • 39,256
  • 9
  • 74
  • 101