[tlamponi]

In that case one can just branch off a stable-x.y branch from the respective X.Y release tag as needed.

It really depends on the whole development workflow, but in my experience it was always easier and less hassle to develop on the main/master branch and create stable release or fix branch as needed. With that one also prioritizes on fixing on master first and cherry-pick that fix then directly to the stable branch with potential adaptions relevant for the potential older code state there.

With branching of stable branches as needed the git history gets less messy and stays more linear, making it easier to follow and feels more like a "only pay for what you actually use" model.

[just6979]

"with potential adaptions relevant for the potential older code state there"

And there it is. Not "potential adaptations", they will be a 100% necessity for some applications. There are industries outside webdev where the ideals of semver ("we do NOT break userland", "we do NOT break existing customer workflows", https://xkcd.com/1172/) are strongly applied and cherry-picking backports is not a simple process. Especially with the pace of development that TBD/develop-on-main usually implies, the "potential older code state" is a matter of fact, and eliding the backport process into "just cherry-pick it" as you did is simply not viable.

[tlamponi]

At work, we do what I wrote frequently, and it works very well and adaptions are rather the outlier than the norm, especially as we focus on backporting only important bug fixes and especially security fixes. We do also pour quite a bit of effort into separating changes into actual sensible commits (not just PRs), which is a bit of work but pays off dramatically if one has older releases they want to provide security and (grave) bug fix support. I.e., this is not just some random thought experiment, my staff and I successfully employ this approach for well over a decade (and about another decade before my time at the company).

Sure, not all workflows are a good fit for this, that's why I started with a disclaimer. But, if you want to do stable release in general, then it's IMO better to adapt the general workflow to that (which provides other benefits too, like on bisecting or when writing actually good release notes), than trying to force that on a not so compatible workflow.

But I'd be happy to hear alternatives, like how you solve this; always interesting to read others perspectives that lay out their solutions (not just why mine doesn't work 1:1 for you, which is basically a given for any non-trivial project).

[just6979]

Not sure I need to give any example solutions, because you've already explained that your solution isn't great, "mine doesn't work 1:1 for you, which is basically a given for any non-trivial project", and that applies for most solutions. But I will:

* GitFlow isn't perfect, but works for many, especially projects with lots of contributors working concurrently, and double especially if there are release gates that keep a human (release engineers) in the CI/CD loop for accountability, which is not uncommon in real world commercial projects. * GitHubFlow works for lots, but not all. Pretty good for moderate team sizes with some but not so much concurrent overlapping work, and perhaps a dedicated release engineer to handle those "potential adaptations". * TBD works for some, but can be inappropriate for many, especially when there are long-lived stable branches with commitments to ongoing security and bugfixes and the team size is smaller such that dedicated release engineers are not a thing.

This list is obviously not comprehensive, and just pulls from some workflows commonly presented elsewhere in this post.

Basically, I was just saying that one _can't_ just "[fix] on master first and cherry-pick that fix then directly to the stable branch with potential adaptions", because in most projects (non-trivial, as you said, which probably means anything with more than a couple contributors and an actual concept of a "stable branch") there will always be adaptations that need to be considered to maintain the stableness of that stable branch. And that's stableness from the user/customer/client PoV of "it acts the same but with less undefined behavior [read: bugs]", not just the dev PoV of "tests pass and it doesn't crash".