On Tue, Aug 25, 2020 at 7:13 AM Jonas Hahnfeld <hah...@hahnjo.de> wrote:
> > I know I'll regret it because I still don't know what objective > criteria others have, but as you really insist on a statement: > in the week of 14th of September (this year, 2020, just to be clear) > or put differently: right after 2.21.7, from that very tag > As said before, I wouldn't make any commitment on the date of the final > release. > > > Rather than a date, I'd prefer a criterion. Once we have an unstable release with the build system in good shape (all the auxiliary scripts work well, the website builds correctly, the MacOS build is functional at least on MacPorts), I'd be in favor of creating a pre-release candidate (which in the past has *not* been a stable branch, but a big bump in the version number; the CG refers to this as an alpha) and implementing the Build-frozen state listed in the CG. After we've had some time to get the alpha release tested, we announce a beta release and branch stable. I concur with the idea that a properly functioning full conversion to Python 3 and workable (though not required) Guile 2 constitutes sufficient change for the next stable version. No other features are needed. I recommend against creating a stable branch too soon. In my experience, we get much more testing on the unstable branch than on the stable branch. People are likely to use the most recent unstable release as a matter of course; they are much less likely to go check out the most recent stable (but not yet released) branch. THanks, Carl