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