Gitflow is more complex for sure (although there's less-complex alternatives that work just as well, but that aside), but it's with reason and allows for parallel maintenance of released versions in more traditional applications where multiple versions may be alive, e.g. non-evergreen desktop applications and server software.
It's added complexity and it has a cost, but there are good reasonings for it. Trunk-based and not-gitflow is fine for SaaS services or web applications I'm sure, the things that CAN be deployed in a continuous deployment fashion.
Gitflow merges everything to a linear 'master' branch, from which releases are tagged. That means you can't create new 1.x releases after 2.0 has been tagged.
In TBD you'd have most new development happening on trunk, but there's no reason you can't spin off a release/v1.x branch as well as a release/v2.x branch from the trunk. The point is just that these shouldn't merge back into trunk -- they're spun off forever.
You can cherry-pick patches onto release branches, but you need to figure out what that means on a case-by-case basis. There's no guarantee that the patch will apply cleanly, and there's no guarantee that it will make sense, even if it does apply cleanly. No branching strategy can fix this for you.
Eh - it's really a conversation about how dogmatic you want to be here.
You have all the info you need with gitflow to go back to the state of a specific release, and then create additional releases based on that state.
Basically - there's nothing stopping you from going back to your 1.0 tag well after release 2 or 3 or even 4 are out, and then branching from there and creating a new 1.x release.
You have a wrinkle left over afterwards, since you now need to determine if any of those 1.x changes should actually make it back into develop (and this is really a case by case question) and you also (at least in my opinion) need a really valid reason for creating the extra maintenance of this wrinkle, but large paying customers can sometimes be a valid reason.
I think you have to tackle the same problem with TBD - there are certainly times when "spun off forever" is acceptable, but there are times when you genuinely want some of the work done on an old release to make it back into the mainline trunk.
---
Long story short... just prefer not to be dogmatic about these decisions and you can generally make most things work. Your customers don't give a flying fuck how you handle branches, and it should really be a consequence of what the team needs right now, rather than a "set in stone" process.
I agree about being pragmatic and doing what the business needs are at the moment!
But that's also why I argue for having less process up front and creating it as needed. The master branch exists solely for the aesthetic reason of having a linear history from version to version. This is obviously incompatible with a non-linear version history.
Simplify the initial process by getting rid of master and tagging directly on the release branch.
In fact, the merge from release branch to master is a bit suspicious. I'd expect the contents of the merge to be precisely the contents of the release branch, regardless of what was on master previously. If not, what am I releasing?
Yup - I agree. I think we'd get along just fine :)
It can be nice to generate release notes from the commits in the merge between the latest release and master, but you can honestly get the same info in a variety of ways (and depending on the team - it may be particularly noisy)
Basically - I think as long as tagging is happening somewhere, and that tag reflects the actual code released, I don't really have a strong preference on the branching around the process. Sort of an implementation detail that doesn't matter that much.
Gitflow is pretty much a traditional, decades-old, trunk plus release branches model, but with an extra branch that does nothing but receive merges, and the names switched around. Well, and feature branches live longer than in TBD (where an implicit feature branch exists on a developer machine between pulling and pushing). It's 95% a different way of describing an age-old workflow.
Why do you think this? There is nothing about trunk-based development that rules out having several live release branches. Google is the poster boy for TBD in the article, and in their main monorepo there are always numerous live release branches but it is still trunk-based. Fixes go into main and are down-integrated to the releases.
It's added complexity and it has a cost, but there are good reasonings for it. Trunk-based and not-gitflow is fine for SaaS services or web applications I'm sure, the things that CAN be deployed in a continuous deployment fashion.