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?