How to version, with semantic version, when a bug is fixed between a stable version and unstable version

semantic-versioningversioning

I have a doubt with semantic versioning. I'm working with semantic version like is shown in semver

Imagine this scenario:

  • A stable version, named as 1.1.0
  • An unstable version, named as 1.1.1-rc1
  • A bug is discovered in stable version 1.1.0 and you need to fix it asap
  • 1.1.1-rc1 version is deployed in a test enviroment, but has not been validated yet

So, what would be the version that solves the bug? I mean, is a rename of 1.1.1-rc1 into 1.1.2-rc1 and solve the bug in 1.1.1 a good practice?

Or is needed a different approach?

Best Answer

from the SemVer spec https://semver.org/

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.....

...Pre-release versions have a lower precedence than the associated normal version

... Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found

So it seems you can have 1.1.1-rc1 and 1.1.1-rc2

To be honest though, I think this pre-release stuff makes a mockery of versioning and testing. Release or don't release 1.1.1 and follow with 1.1.2 if you fix a bug.

If you have more than one supported version then make sure they are different major versions or you will need the fourth version number.

--Edit,

I think the question has been edited a bit since my answer.

re: what should I call v1.1.0 + urgent bug fix, when 1.1.1-rc1 is already in the pipeline but wont be released quickly enough for me?

Well, there's no rule that you have to release every version, 1.1.1 has failed testing, because you know know about this urgent bug. release 'v1.1.0 + urgent bug fix' as 1.1.2-rc1 and then 1.1.2 as per your normal procedure.

I can see your objection would be 'but we are talking about 1.1.1 having a new feature, releasing 1.1.2 without the feature will confuse customers and reveal that we missed this bug!'

To which I say, if its a new feature it should at least be 1.2.0 if not 2.0.0! the third digit is for patches, not features. Do the feature as 1.2.0, 1.2.1... etc and you can continue with 'urgent' fixes without the feature on 1.1.3, 1.1.4 etc.

I know some companies are contractually obliged not to update the major number, if you are in a similar situation perhaps you need to add the forth version number and have 1.1.1.2?

Don't get into the situation where there is fear about upping the version number to correctly indicate different builds. Someone somewhere has that version 1.1.1 you released by mistake and needs 1.1.2 not 1.1.1 (corrected, hope no one notices!!)

Related Topic