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

Question

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?

• David Arno: Creating a rc version of a bug-fix release seems like the bad practice. But since you are there, I think your only option is to go for your rename and publish approach.
• Dan Pichelman: I suspect English may not be your first language. I have edited your question to hopefully make it easier to read. If this is incorrect, please edit your question and roll back the changes (or make your own).
• Reinstate Monica: The real problem is that when you start working on "the version after" 1.1.0, you don't yet know that it's going to be 1.1.1. It could end up being 1.1.2 or even 1.2.0.
• Miguel Ángel García Gómez: Thanks @DanPichelman, as you suspect, English is not my mother tongue, so any improvements are appreciated :)
• Miguel Ángel García Gómez: Thanks for your answer @DavidArno, so what is the recommendation when you have to create a bug-fix release?

Answer 1

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!!)

• David Arno: "To be honest though, I think this pre-release stuff makes a mockery of versioning and testing". +100.

Answer 2

It should be relatively easy to test and deploy a patch. I would recommend making the change in 1.1.1 by creating a 1.1.1-rc2 with the critical bug fix, get it fully tested per your release process, and release 1.1.1 as soon as possible. Maybe you had more bug fixes planned for 1.1.1, but if there's a critical bug, it may be worth getting 1.1.1 out faster and then put the remaining bug fixes into a 1.1.2 or 1.2.0 release depending on if it's only bug fixes or it also includes backward-compatible new functionality.

Answer 3

Here is an approach which fits perfectly into the SemVer versioning scheme:

• assume for a moment the changeset from 1.1.0 to 1.1.1-rc1 had introduced unexpected issues, just as if your testers found this during testing (it does not matter that this not really true, just behave as if it were)

• so rollback all changes from 1.1.0 to 1.1.1-rc1 (which means: start with the stable baseline "1.1.0" again). You can give this code the version number "1.1.1" if you like (you know it is stable since it is effectively identical with 1.1.0, only with a changed version number, so no need for any "rc" label any more). Then you add only the urgent bugfix (I guess it might be so urgent you are going to bypass your normal QA, at least it will be tested before anything else, without any "rc" labeling). According to SemVer, this results in version "1.1.2", the version which gets quickly deployed to production.

• then re-introduce the original patchset from "1.1.0 to 1.1.1-rc1" into "1.1.2". According to SemVer, this becomes "1.1.3". Add "-rc1" again if you prefer this and deploy it to your test environment.

So the resulting sequence of versions is just the linear sequence

 1.1.0 stable baseline
 1.1.1-rc1 unstable test version, containing a changeset A
 1.1.1 stable version, but A reverted (so identical with 1.1.0)
 1.1.2 stable version, including only urgent fix B, but not A
 1.1.3-rc1 unstable test version, containing A and B

This follows all rules of SemVer, and you don't have to "rename" or "relabel" any existing version. The intermediate version "1.1.1" lives only for a very short period in time, only as a working copy for a minute - or less - at the workstation of the developer who integrates the urgent bugfix.