16

I'm having trouble to understand how to deal with the following scenario:

  1. Feature A is committed to master as commit A.
  2. We are ready for release v1.0.0 so we tag commit A as v1.0.0 and we create a release branch rel-1.0.x from it for QA.
  3. Feature B is committed to master as commit B.
  4. QA approves v1.0.0, we deploy and delete the rel-1.0.x branch.
  5. We are ready for release v2.0.0 so we tag commit B as v2.0.0 and create a rel-2.0.x branch from it for QA.
  6. A bug is found in production (v1.0.0) and must be fixed and deployed right away.

At this point I'm not sure how we should handle that. If the bug is in the trunk we could create a hotfix branch from the trunk, fix the bug and merge into the trunk. Then, create a rel-1.0.1 branch from v1.0.0, cherry-pick the fix from the trunk, tag it as v1.0.1 and deploy.

Now what I find odd is that the v1.0.1 commit is not as-is in master given it's been cherry-picked from master and tagged in the rel-1.0.1 branch. Furthermore, if the fix is also needed in rel-2.0.x then how should we handle this? Should we cherry-pick the bug-fix from the trunk again and tag it as a different version, such as v2.0.1?

Here's the kind of graph I'd be getting doing the above (note that v1.1 represents version 2.0 of the text above and that it's the Second feature A fix that occurred while preparing the v1.1 release.):

enter image description here

plalx
  • 42,889
  • 6
  • 74
  • 90
  • I dont get what bothers you with the approach you described. Seems fine to me – Francesco Aug 04 '17 at 21:02
  • @Francesco It kinda feels weird to me that all versioned commits don't end up in `master` (e.g. v1.0.2 and v1.1.1)? Is that usual? I also often read that cherry-picks are to be avoided, but here I'll almost always cherry-pick bug fixes. It also annoys me that the introduction of the same fix yields two new hotfix version numbers. One for the currently released version and one for the release in preparation. – plalx Aug 04 '17 at 21:52
  • I have nothing against cherry picks. And I dont see anything wrong with release tags not in master. My suggestion is to do what works for you. Trunk based is great but It can be adapted. And there is no reason why you cannot change your flow after a bit of experience – Francesco Aug 04 '17 at 22:16
  • If the hotfix branch also need to apply to your current release branch `rel-2.0`, it's ok merge or cherry-pick changes from `hotfix` to `rel-2.0` and then tag a new version. – Marina Liu Aug 07 '17 at 01:29

1 Answers1

0

Coming back to this question, it seems like my concerns were not founded and the versioning/tagging approach as well as the workflow described in the above question is acceptable and works just fine in practice.

One challenge I've faced though is when master incrementally diverges more and more from what's in production. This could happen for many reasons, such as having commits in master that were in theory ready to get released, but somehow didn't go in production. The way I've dealt with that problem is by continuously re-working the commit tree in production so that what diverges stays on top.

plalx
  • 42,889
  • 6
  • 74
  • 90