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 ...):
What happens if this happens instead between version 0.10.0 and 0.50.0? (i.e. we do not guarantee a stable API)?
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)?