[Discussion] Bug fixes across branches

[robbie-demuth]

First of all, I wanted to say thanks for providing a great explanation of how to effectively leverage Git tags and branches in order to support workflows for releasing semantically versioned artifacts. I'm currently working to define the release process for a project I'm working on and found this extremely useful.

I wanted to discuss the Bugfixes section in a bit more detail. In particular, you mention that bugfixes in a patch release can be ported to the branches for minor and major releases by merging upwards. You also describe how bugfixes in master can, if necessary, be ported to the branches for minor and patch releases by cherry picking downwards.

What are your recommendations for porting bugfixes not upwards or downwards, but across branches? Let's say, for example, that I've released v1.0.0, but am still working toward v1.1.0 when an issue is noticed with the former. In this situation, it makes sense to branch from v1.0.0, fix the issue, and merge the branch back into release/1.Y because v1.1.0 has not yet been released. What if it has been released and is also affected by the issue? Given that minor versions shouldn't introduce backward incompatible changes, should the release/1.0.z branch be merged into the release/1.1.z branch or should the issue be fixed directly in release/1.1.z without providing a fix in release/1.0.z?

In the same light, what if v2.0.0 has already been released and is also affected by the issue? I assume in this case that the merge into release/2.0.z is necessary given that users may have a more difficult time adopting the new major version. Does that make sense?

I hope creating an issue for this discussion is okay. If not, feel free to close it and let me know what I should do instead. Thanks!

[bast]

Thanks for opening the issue! Definitely OK to discuss here. I will soon come back with a more useful comment but now traveling :-)

[bast]

I just discussed this with Roberto. Great questions and let's not close this issue until we address this in the text since these are good questions and the text is not too clear on this.

Bugfix detected in v1.0.0 while v1.1.0 is not released yet

I agree. In this case the pull request would probably originate from v1.0.0 and should be directed to the release/1.y branch. The maintainer may ask for the bugfix to be rebased on release/1.y but probably it is not necessary.

Bugfix detected in v1.0.0 after v1.1.0 has been released

I agree. Depends a bit on the ambition of supporting versions. Since it's API-preserving, it's probably OK to direct this pull request towards release/1.1.z (maintainer may ask for the PR to be rebased) and never release a v1.0.1.

If the ambition is to release a v1.0.1, then the PR should be directed towards release/1.0.z and then merged or cherry-picked to release/1.1.z or release/1.y (depending on ambitions).

Bugfix detected in v1.0.0 after v2.0.0 has been released

I agree. In this case we probably want to make life not too difficult for users/libraries depending on v1 by saying "if you want this bugfix you have to change the API calls as well". But again, depends on ambition. But if we still support v1, then I would apply the change to the lowest number that I still support and merge or cherry-pick or re-apply to higher numbers that are still active.

Side-notes

In short the fix/change should be directed to the lowest number branch that we still want to support and merge or cherry-pick (if merge is not possible) or manually re-apply (if cherry-pick is not possible) to all higher number branches that we still want to support.

The model looks heavy-weight and in real life all the fine grain may not be needed. It could also give the impression that no work is happening on master except API-breaking work. "Soon" I would like to comment on this in the text and also present light-weight versions of it for small projects with very few users who do not need to support many versions. Most of my projects are really small and the heavy artillery with a 3-level branching is not really present although the ideas are still followed so I would like to soon write that down.