Jonas Hahnfeld <hah...@hahnjo.de> 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