Jonas Hahnfeld <hah...@hahnjo.de> writes: > Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld: >> Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys: >> > Here is my proposal for how to go ahead: >> > >> > * we build a 2.21.6 from master, and announce it widely as a 2.22 >> > pre-release version. >> >> Adding Phil. I did a full test build of current master yesterday and it >> worked fine with https://github.com/gperciva/gub/pull/80 in place. >> With respect to wording, every 2.21.x is some kind of pre-release for >> 2.22. If this proposal gets consensus, I'd emphasize that feature >> development is over, but I'll leave that to native speakers 😉 >> >> > * we institute a X week freeze; during the freeze, we only merge >> > - fixes for regressions >> > - updates to the documentation >> > - cleanups with no functional changes, with little risk (ie. refrain >> > from build system changes, for example). >> > * after the X week freeze, if we still have open regressions, we tack >> > on another few weeks of freeze to fix them. >> > * if there are no regressions left, we branch stable/2.22, and release >> > a new pre-release. >> > >> > X could be up for discussion, but 3 or 4 weeks seems long enough to >> > gather some feedback, but short enough that experimental/feature work >> > should not be affected. >> > >> > The objective of the freeze is to focus developer energy on fixing >> > regressions rather than causing new regressions. >> >> Sounds good to me. > > To arrive at a decision, what do others think about this? Having a > large silent mass is not really helpful for this kind of discussion (as > it wasn't for the switch to GitLab).
Frankly I don't see the point in repeating points I already made and call that "discussion". I don't see that in the current stage of upheaval of both internals and build system and infrastructure, there is a point in freezing off some half-baked intermediate state that hasn't seen significant exposure to extensive testing. -- David Kastrup