[jeffbee]

I don’t get it. Nothing about trunk-based prevents multiple live release branches. It’s the direction of development that changes. You never work on the release branch, but you do down-integrate relevant changes from trunk to release.

[kkapelon]

Customer A wants feature X now. Customer B wants feature Y now. X and Y are conflicting with each other.

You can either spend 4x the amount of time to make them compatible (and still follow TDB) OR spend x time and just deliver to each customer the respective feature only (and no longer follow TBD)

[jeffbee]

Your whole argument hinges on "are conflicting with each other". I am confident that in many cases I would be able to put the X stuff in x_lib and the Y stuff in y_lib and link two different binaries for them, from head.

[kkapelon]

"put the X stuff in x_lib and the Y stuff in y_lib" is exactly what takes 4x amount of time

Also this process can continue. In the next iteration you have will 3 incompatible features with the same or different customers.

If you use different branches you can always to go to branch X and know exactly what is deployed on customer X.

In your case the only way to recreate what customer X has is to find the proper combination of libraries that you have shipped to them so far.

Imagine I am a developer and want to do a hotfix for a specific customer. I can just do git checkout branch-of-customer and start working. Isn't the process more difficult with your approach?

[cassianoleal]

This is one of the points where the dogma breaks down.

If trunk has changed substantially from the release branch where the patch is required, you can't cherry-pick and you need to work on the branch.

[jeffbee]

I of course cannot support dogma when it comes to software development. Pragmatism carries the day every time. But rare cases where a fix from head has to be edited to apply on a release branch does not invalidate the other advantages of trunk-based development, and there are ways to avoid the need to do such edits, including making sure that the pace of retirement of old releases is consistent with the pace of development on mainline.

[cassianoleal]

Yes, agreed. Unfortunately as with most software development process fads, most of the TBD advocates I've met fail to understand that nuance.

Mind you, I've been "doing TDB or a variation of it," and advocating for it for as long as I can remember. Still, as soon as TBD was given a name and evangelists started sprawling and calling me a heretic because I favoured pragmatism in many instances, I started disliking the dogma as a whole.

I'm fine with using it as a discussion starter. Always look at principles and outcomes though. If the dogma gets in the way, discard the dogma and do what will work given your teams, their culture and their maturity.