Re: To branch or not to branch

[Lukas-Fabian Moser]

> > 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.

Lukas