[openssl-project] 1.1.1 Release timetable

[Matt Caswell]

On 23/12/17 00:56, Richard Levitte wrote:
> In message <ad1cc8dd-f85c-9588-90fd-316a42ff91a4 at openssl.org> on Sat, 23 Dec 2017 00:32:07 +0000, Matt Caswell <matt at openssl.org> said:
> 
> matt> 
> matt> 
> matt> On 22/12/17 18:43, Richard Levitte wrote:
> matt> > In message <455316cf-cc58-c102-e723-eaaf89b21b96 at openssl.org> on Fri, 22 Dec 2017 17:17:17 +0000, Matt Caswell <matt at openssl.org> said:
> matt> > 
> matt> > ...
> matt> > matt> 1.1.1 Release timetable proposal
> matt> > matt> ================================
> matt> > matt> 
> matt> > matt> With all of the above in mind here is my straw man proposal for 1.1.1:
> matt> > matt> 
> matt> > matt> 23rd January 2018, alpha release 1 (pre1)
> matt> > matt> 20th February 2018, alpha release 2 (pre2)
> matt> > matt> 	OpenSSL_1_1_1-stable created (feature freeze)
> matt> > matt> 	master becomes basis for 1.1.2 or 1.2.0 (TBD)
> matt> > matt> 20th March 2018, beta release 1 (pre3)
> matt> > matt> 17th April 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published)
> matt> > matt> 
> matt> > matt> An alpha release means:
> matt> > matt> - Not (necessarily) feature complete
> matt> > matt> - Not necessarily all new APIs in place yet
> matt> > matt> 
> matt> > matt> A beta release means:
> matt> > matt> - Feature complete/Feature freeze
> matt> > matt> - Bug fixes only
> matt> > matt> 
> matt> > matt> Note that alpha release 2 may have new features in it, but we will
> matt> > matt> freeze at that point so that beta release 1 will not have new features.
> matt> > 
> matt> > That is perfectly contradictory.  You write it yourself, and alpha
> matt> > release means "Not (necessarely) feature complete", but if you do a
> matt> > feature freeze with alpha 2, then there's no space to complete the
> matt> > features that may remain.  So in practice, you're making alpha 2 a
> matt> > beta.  I am *strictly* opposed to this confusing message.
> matt> 
> matt> Your way seems even more confusing (to me).
> matt> 
> matt> Looking at this from a user's perspective, if we say that a beta release
> matt> has no new features and only contains bug fixes, then this implies
> matt> "since the last release". Therefore the logical conclusion is that beta
> matt> rules apply from the beginning of the development phase for that
> matt> release. The development phase for the beta release starts as soon as
> matt> the last alpha is done. Therefore the feature freeze should apply from
> matt> that point.
> 
> I disagree with your interpretation.  Mine is that going into beta
> means "From this point on, there will be no more added features",
> which is essentially what a feature freeze means, and that is also
> what people usually mean.
> 
> Ref: https://en.wikipedia.org/wiki/Software_release_life_cycle
> 
> Note that in that article, they say this about the Alpha phase:  "The
> alpha phase usually ends with a feature freeze, indicating that no
> more features will be added to the software."
> 
> The last alpha release doesn't mark the end of an alpha phase, the
> first beta does.
> 
> "Beta phase generally begins when the software is feature complete but
> likely to contain a number of known or unknown bugs."
> 
> This is what people expect when you say alpha and beta, and this is
> how we have behaved before.  Why we should act differently now is a
> mystery to me...  or well, I can see that there's a desire to rush
> things because of the anticipated publication of TLS 1.3.  However, I
> think it's the wrong move, and even more so by blurring the usual
> meaning of alpha and beta.

This has nothing to do with a desire to rush things (far from it). If
anything the opposite. It comes from my perception that in 1.1.0 we had
too many unstable releases and too few stable ones. In part I view this
was because the first beta was not in fact stable, but was unstable
because of last minute feature additions which goes contrary to my view
about what a beta release should be about. Ultimately though if the team
view is that feature freeze starts with beta 1 then the same effect can
be achieved by relabelling the releases in my original plan:

23rd January 2018, alpha release 1 (pre1)
20th February 2018, beta release 1 (pre2)
	OpenSSL_1_1_1-stable created (feature freeze)
	master becomes basis for 1.1.2 or 1.2.0 (TBD)
20th March 2018, beta release 2 (pre3)
17th April 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published)

Matt