[openssl-project] 1.1.1 Release timetable

Sat Dec 23 00:56:06 UTC 2017

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.

matt> > In message <1b61a29b-035e-9786-c8e9-d3feb0888340 at openssl.org> on Fri, 22 Dec 2017 18:10:05 +0000, Matt Caswell <matt at openssl.org> said:
matt> > 
matt> > matt> I think compressing the release cadence to less than 4 weeks (which is
matt> > matt> implied by your suggestion) is overly ambitious and could be setting
matt> > matt> ourselves up to fail. If you want to bring the final release date
matt> > matt> earlier then one possibility is to drop the second alpha release, so the
matt> > matt> timetable becomes:
matt> > matt> 
matt> > matt> 23rd January 2018, alpha release 1 (pre1)
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 February 2018, beta release 1 (pre2)
matt> > matt> 20th March 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published)
matt> > matt> 
matt> > matt> Doing it that way still gives us the best part of 2 months to work on
matt> > matt> the release criteria (i.e. closing off old issues). Another option is to
matt> > matt> relax the release criteria, so we need less time to work on them.
matt> > 
matt> > And with this, you're proposing that our release cycle starts with a
matt> > beta in practice, no matter what you call it.  I am *brutally* opposed
matt> > to this plan.
matt> > 
matt> 
matt> Well, I am not enthused by this version of the plan either. It was only
matt> put forward as a possible way of achieving Rich's desire for a March
matt> public release. I think my initial plan version with the extra alpha
matt> release is better. I've not yet heard a justification for why we should
matt> be targeting March. If it's to line up with the earliest reasonable date
matt> that we expect the TLS1.3 RFC to be published then that doesn't seem
matt> like a good enough reason to me.

Thank you, we seem to agree.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/