Re: branching stable/2.22?

[Jonas Hahnfeld]

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