[GH-ISSUE #485] Effect of hotfixes on other planned releases #2092

New Issue

GiteaMirror · 2026-04-20T10:01:54-05:00

GiteaMirror commented

2026-04-20 10:01:54 -05:00

Originally created by @jbotuck on GitHub (Jan 10, 2019).
Original GitHub issue: https://github.com/semver/semver/issues/485

Let's say I have 1.0.1 in Production. The dev team is working on 1.0.2-SNAPSHOT (where SNAPSHOT is a pre-release) which they plan on releasing as 1.0.2 in a week. They have lots of untested changes in the 1.0.2-SNAPSHOT code. Suddenly a critical bug is discovered in 1.0.1 that needs to be fixed NOW! The dev team creates a hotfix for the 1.0.1 code. None of the 1.0.2-SNAPSHOT code is in the hotfix. What version should we use for the hotfix? If we use 1.0.2, we give the false appearance that 1.0.2-SNAPSHOT is associated with 1.0.2! Also we would need to do a lot of bookkeeping and paperwork to change next weeks release to 1.0.3. Any good ideas about what to do in this situation?

Originally created by @jbotuck on GitHub (Jan 10, 2019). Original GitHub issue: https://github.com/semver/semver/issues/485 Let's say I have 1.0.1 in Production. The dev team is working on 1.0.2-SNAPSHOT (where SNAPSHOT is a pre-release) which they plan on releasing as 1.0.2 in a week. They have lots of untested changes in the 1.0.2-SNAPSHOT code. Suddenly a critical bug is discovered in 1.0.1 that needs to be fixed NOW! The dev team creates a hotfix for the 1.0.1 code. None of the 1.0.2-SNAPSHOT code is in the hotfix. What version should we use for the hotfix? If we use 1.0.2, we give the false appearance that 1.0.2-SNAPSHOT is associated with 1.0.2! Also we would need to do a lot of bookkeeping and paperwork to change next weeks release to 1.0.3. Any good ideas about what to do in this situation?

GiteaMirror closed this issue

2026-04-20 10:01:55 -05:00

GiteaMirror commented

2026-04-20 10:01:57 -05:00

@klehelley commented on GitHub (Jan 10, 2019):

Since you use SNAPSHOT as the pre-release marker in your example I assume that you are using Maven? In that case snapshot builds are not meant to stay around for long, and should be seldom used when declaring dependencies (and a projects should not be released if it has even just one such dependency, as it makes the build non-reproducible).

So yeah maybe for a few hours/days you will have old snapshot builds laying around with version numbers making them look like they relate to release 1.0.2, whereas they are actually from the code branch that is used to build future release 1.0.3, but I personally wouldn't sweat it. It won't last.

Actually, even out of a Java environment, one can plan a future X.(Y+1).0 release and have to follow if priority changes completely midway through developing it, and work on other features while keeping the ones they had worked on so far aside to work on later. The truth is, even using SemVer, the version number alone is not enough to tell the whole story. You need to have ways to document how work is planned and performed, what a future delivery is actually expected to contains, etc. It may be more predictable in given settings, but there is no certainty of what the next release will contain or when it will happen, especially with the need of quick hotfixes, or development sometimes being behind schedule, etc.

Oh and if you have a lot of changes to make regarding paperwork, tracking systems, etc. look into simplifying things (if possible), or delaying the decisions that force you to spend too much time updating that kind of documentation.

@klehelley commented on GitHub (Jan 10, 2019): Since you use `SNAPSHOT` as the pre-release marker in your example I assume that you are using Maven? In that case snapshot builds are not meant to stay around for long, and should be seldom used when declaring dependencies (and a projects should not be released if it has even just one such dependency, as it makes the build non-reproducible). So yeah maybe for a few hours/days you will have old snapshot builds laying around with version numbers making them look like they relate to release 1.0.2, whereas they are actually from the code branch that is used to build future release 1.0.3, but I personally wouldn't sweat it. It won't last. Actually, even out of a Java environment, one can plan a future `X.(Y+1).0` release and have to follow if priority changes completely midway through developing it, and work on other features while keeping the ones they had worked on so far aside to work on later. The truth is, even using SemVer, the version number alone is not enough to tell the whole story. You need to have ways to document how work is planned and performed, what a future delivery is actually expected to contains, etc. It may be more predictable in given settings, but there is no certainty of what the next release will contain or when it will happen, especially with the need of quick hotfixes, or development sometimes being behind schedule, etc. Oh and if you have a lot of changes to make regarding paperwork, tracking systems, etc. look into simplifying things (if possible), or delaying the decisions that force you to spend too much time updating that kind of documentation.

GiteaMirror commented

2026-04-20 10:01:57 -05:00

@steveklabnik commented on GitHub (Feb 11, 2019):

This is not really the kind of thing the spec can (or should, IMHO) legislate. As such, I'm going to give it a close. Thanks!

@steveklabnik commented on GitHub (Feb 11, 2019): This is not really the kind of thing the spec can (or should, IMHO) legislate. As such, I'm going to give it a close. Thanks!

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/semver#2092