Re: 2.20 and 2.21 release plans

[Jonas Hahnfeld]

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

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

Jonas

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