[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: branching stable/2.22?

From: Jonas Hahnfeld
Subject: Re: branching stable/2.22?
Date: Tue, 25 Aug 2020 23:04:07 +0200
User-agent: Evolution 3.36.5

Am Dienstag, den 25.08.2020, 07:51 -0600 schrieb Carl Sorensen:
> On Tue, Aug 25, 2020 at 7:13 AM Jonas Hahnfeld <> 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. 

Are you sure this is what happened in the past? I mean I didn't
participate, so all I can rely on is git and the mailing list archives.

For 2.18, I see
 - release/2.17.29-1 tagged on 20 October 2013
 on 22 October 2013
 - release/2.17.95-1 tagged on 04 November 2013
 on 05 November 2013
As far as I understand, stable/2.18 was created before 2.17.95 (which
was incorrectly released from master, see above). The merge base
between current master and stable/2.18 points to April 2014 which is
probably due to a partial merge? Certainly after 2.18.0 had been
released in December 2013.

For 2.20, I see
 - considerations in December 2016:
 on 06 June 2017
 - release/2.19.65-1 tagged on 06 August 2017
 - merge-base HEAD stable/2.20: 0712559601, committed 08 August 2017
and merged into stable/2.20 on 16 August 2017
 on 16 August 2017
 - release/2.19.80-1 tagged on 16 October 2017

This looks like the release candidates (coinciding with the big bump)
have (or should have been) released from the stable/ branches?

That said, I'm not opposed to doing a pre-release candidate from master
and git history tells little about possible freezes. Just trying to
understand what might have worked in the past...

> 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

Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]