Re: 2.20 and 2.21 release plans

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
>> Ok, I think 2.20 is basically done and we should push it out by the end
>> of this week.  This leaves a few days for the translation team to catch
>> up with the current state.
>
> Wohoo!
>
>> [...]
>> 
>> What does this mean for 2.21.0?  I think we should aim to push it out
>> fast afterwards, basically a few days later at most, just to get kinks
>> with webpage/versioning from 2.20 ironed out.
>> 
>> [...]
>> 
>> For more extensive changes of internals and/or syntax, I would recommend
>> to let them sit till 2.21.1 before committing, assuming that we _do_
>> manage to get 2.21.0 out fast.  Why?  2.21.0 has by now quite
>> significantly diverged from 2.20.0.  If something does not quite work,
>> it would be nice to have a _released_ version to compare to, and nothing
>> but 2.21.0 would really serve that role satisfactorily.  Particularly
>> where problems are detected a long time after getting introduced, having
>> an installable version as a reference is nice, and "it stopped working
>> in 2.21.0" is enough of a quagmire already that we do not really want to
>> add a lot more here.
>
> Sounds good (well, Python 3 is already in). To be sure: This also means
> we'll be using GUB for 2.21.0? I'd like to propose a new system (yes,
> *with* support for Windows) soon, but not sure that I can make it in
> the next week or so...

Yes, GUB for 2.21.0.  We don't want to have another indeterminate
backlog on unstable releases.  That means that GUB needs to get switched
over to Python 3.  It may make it more prudent, should we need to
release 2.20.1 at some time, to also go to the cherry-picking nightmare
required to bring stable/2.20 up to Python 3.  Definitely a holdup I
would not have wanted for 2.20.0.

If we want to switch over to a different release method, we can do that
comfortably without unstable releases being blocked.  Whether we want to
eventually bring out a 2.20 version in that manner too (which might
bring different platform support) or save it for 2.22 or whenever is
something I don't think we should try pinning down now.

>> The size of the headache basically is commensurate with how long the
>> stable branch has diverged.  Hopefully we manage to find some
>> combination of process and responsible persons next time around that
>> delivers faster.
>
> To throw this idea onto the mailing list: Time-based releases seem to
> encourage a predictable schedule. I don't think it makes sense to have
> monthly stable releases as, for example, GitLab does. But maybe
> tracking something like once in a year to 18 months with defined
> windows for alpha and beta releases?

We have to see how this pans out.  The last release cycle saw something
like a half-year blockage due to GUB problems.  It's not like anybody
wanted this to keep up for as long as it did.  And there is no point in
committing to schedules if there are no persons tied into the
commitment.  It's not like I didn't offer the release manager job for
grabs several times round with no takers.  Committing to regular
schedules with me as sole release manager candidate is a predictable
setup for disappointment.

-- 
David Kastrup