The reference website says that release branches are optional.

1. A release can happen on trunk
2. Or on a release branch

The latter can happen because you might want to “harden” a release. Which I interpret as cutting a release point, testing it, and incorporating urgent fixes. Meanwhile trunk can continue its life with whatever other changes which will not impact the release branch.

Keep in mind that there’s another dimension here:

1. A preemptive release branch (what we just discussed)

2. An after-release release branch

   - - - ★ - ★ - ★ - ★ trunk
          \v1.0
   

The latter here is relevant if you released 1.0, a bug was found and you need some version like 1.0.1 with just that bug fix. But trunk has many more commits at this point. But that’s not a problem. Just check out the tag and make a release branch. Then you can incorporate the change there.

How to incorporate changes between trunk and the release branches

How do you incorporate changes between the eternal trunk branch and the releases?

The reference has its guideline for this:

The best practice for Trunk-Based Development teams is to reproduce the bug on the trunk, fix it there with a test, watch that be verified by the CI server, then cherry-pick that to the release branch and wait for a CI server focusing on the release branch to verify it there too.

Apparently this is the Trunk Based Development approach. But I disagree. This is not the correct approach if you want to handle changes in the best way with Git.

Take the bug on v1.0 example. Is the bug urgent enough to fix on top of v1.0 and make a bug fix version? Then fix it there.

- - - ★ - ★ - ★ - ★ trunk
      v1.0 - ★ (bugfix)

Then merge it into trunk:

- - - ★ - ★ - ★ - ★ - - - ★ (merge) trunk
      v1.0 - ★ (bugfix) /

Now the upcoming v1.0.1 (or whatever it will be) will have the commit. Just query it:

git tag --contains=<bugfix commit>

As does trunk. Just query it:

git branch --contains=<bugfix commit>

You cannot directly query it if you use cherry-picks.

You should also get less merge conflicts since there is less merge-base drift when you avoid cherry-picks. You can imagine multiple releases and multiple cherry-picks on top of release branches or trunk. That means that Git has to go further back to calculate differences when doing future merges.

And if you have multiple releases? Merge upwards from the oldest release to trunk. For the release branches corresponding to these tags:

1. v1.0.1 into 1.5.5
2. 1.5.5 into 1.7.0
3. 1.7.0 into trunk

Imagine having to use cherry-picks for all of that instead. The work compounds.

When cherry-picks might be relevant

The merge approach works well when you apply the change to the correct place from the start. But sometimes you might apply a fix to trunk and then later figure out that you want it in some release branch as well. Use cherry-pick in that case since that’s the only option anyway.

TBD website says not to do this

This should not be done according to the reference website:

You should not fix bugs on the release branch in the expectation of cherry-picking them back to the trunk. Why? Well in case you forget to do that in the heat of the moment. Forgetting means a regression in production some weeks later (and someone getting fired).

(Why not merge instead of cherry-pick?)

The emphasis on “forgetting” seems arbritrary here since their recommended approach is to fix on trunk, then wait until CI passes, then finally cherry-pick to the release branch. Well. What if you forget to cherry-pick that way?

We might risk getting fired here according to their corporate crystal ball. But fixing on the release branch and then merging to trunk is both neater and prioritizes the most immediate need:

1. The upcoming release has the fix
2. You might break trunk with a fix that works well for the release branch but not on `trunk** for some reason, which is a small inconvenience compared to a broken release
3. You have all the time until the next release to remember to merge to trunk before the harm is done
   • Granted this is not a strong point if you release every day
   • But just merge immediately to trunk and don’t worry about forgetting it in the first place

Questions

In TBD, where should version updates (pom.xml changes) happen?

This does not have anything to do with any version strategy. The Maven Masters demand a build to have the correct version. So you need to have that on whatever commit you choose to release on.

What’s the recommended way to handle multiple active versions in TBD without causing confusion or conflicts?

It is poorly thought out. See the reference website again:

Merge Meister role

The process of merging commits from trunk to the release branch using ‘cherry pick’ is a role for a single developer in a team. Or dev pair, if you are doing Extreme Programming. Even then, it is a part time activity. The dev or pair probably needs to police a list of rules before doing the cherry pick. Rules like which business representative signed off on the merge. Perhaps the role should also rotate each day.

Some teams update a wiki to audit what made it to the release branch after branch cut, and some use ticket system as this by its nature interrupting and requiring of an audit trail of approvals.

The “merging” here means cherry-picking all changes that are going into a release.

• A part time activity?
• Police a set of rules?
• Business representative signoff?
• Wiki to audit release branch?

No thanks. All you need:

• trunk is the default target for all development
• But first target the release branch for something that is going into a fix for a release and you cannot do it on trunk (because trunk has moved on and has things that should not go into the fix release)
• Then merge the changes into other release branches (if applicable) and finally trunk

Now, as mentioned, it is simple to query exactly what commits are in what tags and branches. It’s simple to see the discrepancy between any two points in the history. No “wiki to audit” needed beyond the standard fare (maybe issue tracker keys from the commit messages).