Re: To branch or not to branch

[Jonas Hahnfeld]

On Wed, 2022-10-05 at 22:57 +0200, Lukas-Fabian Moser wrote:
> > 
> Forgive me for piping up - it's very well possible that I'm saying 
> something terribly stupid, as I'm not really familiar with the 
> procedures involved in creating a stable release.
> 
> But here's how I read the current discussion: If
> 1) there are good reasons for doing the branching-to-stable after a 
> development release,
> 2) we do not want to do another development release (because it
> wasn't planned and would delay things further),
> 3) development goes on because developers just go on working (which 
> isn't such a bad thing after all) -
> 
> then maybe it would be reasonable to branch from the most current 
> development release, cherry-pick important bug fixes and simply
> declare new features that were added after the last development
> release to be "too late for this stable release round"?

Yes, we could theoretically do this, with a bit of extra effort because
a number of fixes did happen in the mean time that would need to be
picked. It feels a bit "non-linear" to go back to 2.23.13 and create
the stable branch, and then change all mentions of 2.23.14 in master to
2.25.0, but that's probably more a perfectionist's thought.
My more practical concern is that we wanted to run the formatting tools
before branching. If we start from 2.23.13 and want to stick to that
plan, we have to run the tools twice (which is easy) but we'll end up
with two different commits in the stable branch and master, requiring
git to figure out the correct "resolution" when picking fixes. Now, I
don't know exactly how git works for cases like this and if it will be
a relevant problem, but still something to consider.

Overall, this approach feels more like a workaround for not properly
communicating in the first place...

Jonas

signature.asc
Description: This is a digitally signed message part