[GH-ISSUE #917] How to approach hotfix versions? #6566

New Issue

GiteaMirror · 2026-06-17T05:25:30-05:00

GiteaMirror commented

2026-06-17 05:25:30 -05:00

Originally created by @kelso on GitHub (Feb 8, 2023).
Original GitHub issue: https://github.com/semver/semver/issues/917

Situation gets unclear, when your release workflow includes these:

staging server (for testers)
production (for wide public)

Each version tested on staging is then promoted (copied) to the production.

Only suffix mentioned on semver docs is a Pre-release, but is not suitable for the workflow and naming of hotfixes. it's quite the opposite. Docs say:

When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version:
Example: 1.0.0-alpha < 1.0.0.

But -hotfix would have higher precedence than normal version.

Example scenario:

1.1.0 - version deployed to staging server, tested by testers, then released to production server too
1.1.1 - bugfix deployed to staging server, not yet tested nor released to production server

Let's say, then on the production, still running 1.1.0, is discovered a critical bug.

Now we need to release a hotfix version to the production - including only fixes of the critical bug, excluding changes (bugfixes) in 1.1.1 (it is still on staging server only and this version needs to be "approved" by testers confirming the fixes actually work; public didn't see it on production yet)

What is the proper way to name that hotfix version, if the "1.1.1" is already taken?

What about 1.1.0.1? (hotfix for the verion 1.1.0)

I think Ruby on Rails is following the same versioning of 4th number, for releasing security vulnerabilities fixes. Despite they not have the staging/production situation I mentioned.
https://rubygems.org/gems/rails/versions
Or should be staging versions marked as .pre-release, before it goes to production? But, in our case, when staging is promoted to production, nothing is changed. Why mark some 1.5.1.pre-release later as 1.5.1 if it's the same code base.

Thanks for any advice.

Originally created by @kelso on GitHub (Feb 8, 2023). Original GitHub issue: https://github.com/semver/semver/issues/917 Situation gets unclear, when your release workflow includes these: - staging server (for testers) - production (for wide public) Each version tested on staging is then promoted (copied) to the production. Only suffix mentioned on _semver docs_ is a Pre-release, but is not suitable for the workflow and naming of hotfixes. it's quite the opposite. Docs say: > When major, minor, and patch are equal, a **pre-release version has lower precedence than a normal version**: > Example: 1.0.0-alpha < 1.0.0. But -hotfix would have higher precedence than normal version. Example scenario: `1.1.0` - version deployed to _staging server_, tested by testers, then released to _production server_ too `1.1.1` - bugfix deployed to _staging server_, not yet tested nor released to _production server_ Let's say, then on the _production_, still running `1.1.0`, is discovered a critical bug. Now we need to release a hotfix version to the production - **including only** fixes of the critical bug, **excluding** changes (bugfixes) in 1.1.1 (it is still on staging server only and this version needs to be "approved" by testers confirming the fixes actually work; public didn't see it on production yet) **What is the proper way to name that hotfix version, if the "1.1.1" is already taken?** - What about `1.1.0.1`? (hotfix for the verion 1.1.0) I think Ruby on Rails is following the same versioning of 4th number, for releasing security vulnerabilities fixes. Despite they not have the staging/production situation I mentioned. https://rubygems.org/gems/rails/versions - Or should be staging versions marked as .pre-release, before it goes to production? But, in our case, when staging is promoted to production, nothing is changed. Why mark some 1.5.1.pre-release later as 1.5.1 if it's the same code base. Thanks for any advice.

GiteaMirror closed this issue

2026-06-17 05:25:30 -05:00

GiteaMirror commented

2026-06-17 05:25:31 -05:00

@ljharb commented on GitHub (Feb 8, 2023):

1.1.2, which includes all the changes in 1.1.1.

which server it's deployed to is irrelevant imo, once you've cut the version number that's what's published.

@ljharb commented on GitHub (Feb 8, 2023): 1.1.2, which includes all the changes in 1.1.1. which server it's deployed to is irrelevant imo, once you've cut the version number that's what's published.

GiteaMirror commented

2026-06-17 05:25:31 -05:00

@budd3r commented on GitHub (Feb 8, 2023):

I have been wrestling with the same situation, and am interested in how others are handling it.
I don't feel that 1.1.2 satisfies the situation that the author describes.
For example, if the 1.1.0 version was released from a release branch, but the 1.1.1 version (and possibly others for that matter) already exist (possibly due to releasing from a tag on the mainline branch) -- there needs to be a way to include a hotfix on the release branch that is supported by semver.

@budd3r commented on GitHub (Feb 8, 2023): I have been wrestling with the same situation, and am interested in how others are handling it. I don't feel that 1.1.2 satisfies the situation that the author describes. For example, if the 1.1.0 version was released from a release branch, but the 1.1.1 version (and possibly others for that matter) already exist (possibly due to releasing from a tag on the mainline branch) -- there needs to be a way to include a hotfix on the release branch that is supported by semver.

GiteaMirror commented

2026-06-17 05:25:31 -05:00

@ljharb commented on GitHub (Feb 8, 2023):

The only way would be indeed shipping prereleases and promoting them later, even if it's the same code, because then what the non-prerelease status is indicating is "deployed to production".

Either way I don't think semver makes as much sense at the deployed application level; it's more for software that other software consumes imo.

@ljharb commented on GitHub (Feb 8, 2023): The only way would be indeed shipping prereleases and promoting them later, even if it's the same code, because then what the non-prerelease status is indicating is "deployed to production". Either way I don't think semver makes as much sense at the deployed application level; it's more for software that other software consumes imo.

GiteaMirror commented

2026-06-17 05:25:32 -05:00

@steveklabnik commented on GitHub (Feb 9, 2023):

Yes, the way to do this officially is 1.1.2.

You could like try and do something where you only push "prereleases" to staging and then they become "releases" when they hit production, but that seems like a lot of work.

Either way I don't think semver makes as much sense at the deployed application level; it's more for software that other software consumes imo.

I would also agree with this, which is certainly why this feels a bit awkward.

@steveklabnik commented on GitHub (Feb 9, 2023): Yes, the way to do this officially is 1.1.2. You *could* like try and do something where you only push "prereleases" to staging and then they become "releases" when they hit production, but that seems like a lot of work. > Either way I don't think semver makes as much sense at the deployed application level; it's more for software that other software consumes imo. I would also agree with this, which is certainly why this feels a bit awkward.

GiteaMirror commented

2026-06-17 05:25:32 -05:00

@kelso commented on GitHub (Feb 14, 2023):

Thank you for all your comments.

@kelso commented on GitHub (Feb 14, 2023): Thank you for all your comments.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#6566