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). Jonas
signature.asc
Description: This is a digitally signed message part