How do deal with bugs in semantic versioning introduced in old branches

Question

My question relates to semantic versioning (specifically as specified here).

Say I have some feature I introduced in version 1.10.0 and then some time later (let's say the project has advanced to version 1.50.0 for the sake of argument) I discovered a bug with the 1.10.0 version. So my understanding is, we fix that, and that should then be version 1.10.1. So far so good. How does that though look in practice? Do I check out version 1.10.0 again, do the fix here (and in the worst case potentially use internal (not public API) features that may have changed from 1.10.0 to 1.50.0) and then rebase my changes onto version 1.50.0? (this potentially would cause a lot of merge conflect while we replay the master onto the latest commit). Potentially cherry-picking may be better here? (though I have not used that feature myself so I am not sure here). Or, could I apply this bugfix to version 1.50.0 and then make that version 1.50.1, even though the bug fix may not have anything to do with the feature introduced in 1.50.0? The website mentioned above does not seem to have an answer to that ...

There are two additional scenarios I would like to consider, which may result in a different approach to the problem (not sure, but maybe someone could shed some light here, maybe the approach will be exactly as before though ...):

1. What happens if this happens instead between version 0.10.0 and 0.50.0? (i.e. we do not guarantee a stable API)?

2. What happens if this happens instead between version 1.10.0 and, say, 2.0.0 or later (i.e. we guarantee a public API change)?

Answer 1

Say I have some feature I introduced in version 1.10.0 and then some time later (let's say the project has advanced to version 1.50.0 for the sake of argument) I discovered a bug with the 1.10.0 version. So my understanding is, we fix that, and that should then be version 1.10.1. So far so good. How does that though look in practice?

The first question you must ask is if the problem is severe enough to fix it on old (but still maintained) releases, or if it can be fixed just in future releases.

If it is minor enough to fix only in future releases, then the fix should be made on the top of the mainline branch and the version number containing the fix gets determined based on all the contents of that next version.

If it needs to be fixed also on existing, maintained, releases, you should start at the oldest maintained release that contains the problem. You fix the problem on that release and bump the patch-level of the version number. Then you port the fix to every maintained release that follows, bumping all the version numbers in the process. And finally to port it to the development mainline.

How the porting from release to release looks like depends on how the code evolved between the releases, but would most likely consist mostly of either cherry-picking and fixing conflicts or a re-implementation if the affected code changed too much.

In semantic versioning, the patch-level version component is bumped for every release that contains only bug fixes, independent of if those bug fixes are related to the functionality introduced in that minor version or not.

The other two scenarios you mention don't affect the process in a significant manner, although they may increase the likelihood that a re-implementation of the bug fix is needed due to heavy changes to the codebase.