Re: To branch or not to branch

[Jean Abou Samra]

Le 05/10/2022 à 22:57, Lukas-Fabian Moser a écrit :
> > > Honestly, I think that your criteria for creating pre-release of 2.24
> > > are too rigid.  As far as I can see, doing a 2.23.80 release *right
> > > now* is the way to go.
> > Fine, if you disagree with the plan laid out in August, I invite you to
> > volunteer taking care of the releases and the related procedures. There
> > are reasons behind branching after a development release and only doing
> > the release candidate from the branch that make me believe it would
> > still be the right way to go.
>
> 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"?
>
> Of course it's a possible source of frustration for developers if they 
> can't get their favourite new feature into an upcoming stable release, 
> but you have to make a cut at some point, and the way I see it, the 
> (wonderful) fact that we have some very productive developers should 
> neither preclude us from doing a stable release, nor should we ask 
> them to stop their contributions for a while while they're on a roll.
>
> And as I said: Please forgive me if I misunderstand the issue and my 
> reasoning is beside the point.




This isn't absurd, but I have to admit I would be disappointed not to 
see text marks in 2.24. This is actually a discussion we already had, see
https://gitlab.com/lilypond/lilypond/-/merge_requests/1616#note_1095558136

A factor that I was starting to forget in my enthusiasm for branching is 
!1510 (source locations). Here I am guilty of taking forever to prepare 
the latest version of that patch. I am open to opinions on whether it 
should be included in 2.24. I do think so, because the problem it fixes 
has been called a possible release blocker by some.

So how about the following plan:

!1510 could perhaps be merged faster than usual for an MR on Review, 
e.g. on Saturday (it has already been reviewed and the latest update was 
minor changes, I tried a different approach but it was too complex so I 
eventually went back to the previous approach).

Apart from this peculiar MR, we try to create optimal conditions for 
branching by refraining from merging non-bugfix changes to master for a 
few countdowns. (I've just put !1650, the \simple thing, on Waiting.)

On Saturday or Sunday, we do the 2.23.14 release. We explicitly ask 
users to test it, focusing on these points in particular: large scores 
on Windows, -dcompile-scheme-code, and text marks.

If no major issues are reported, we create the branch later next week 
and open master for development again.

Does that sound reasonable?