[openssl-project] 1.1.1 Release timetable

[Richard Levitte]

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> 1.1.1 Release timetable proposal
matt> ================================
matt> 
matt> With all of the above in mind here is my straw man proposal for 1.1.1:
matt> 
matt> 23rd January 2018, alpha release 1 (pre1)
matt> 20th February 2018, alpha release 2 (pre2)
matt> 	OpenSSL_1_1_1-stable created (feature freeze)
matt> 	master becomes basis for 1.1.2 or 1.2.0 (TBD)
matt> 20th March 2018, beta release 1 (pre3)
matt> 17th April 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published)
matt> 
matt> An alpha release means:
matt> - Not (necessarily) feature complete
matt> - Not necessarily all new APIs in place yet
matt> 
matt> A beta release means:
matt> - Feature complete/Feature freeze
matt> - Bug fixes only
matt> 
matt> Note that alpha release 2 may have new features in it, but we will
matt> freeze at that point so that beta release 1 will not have new features.

That is perfectly contradictory.  You write it yourself, and alpha
release means "Not (necessarely) feature complete", but if you do a
feature freeze with alpha 2, then there's no space to complete the
features that may remain.  So in practice, you're making alpha 2 a
beta.  I am *strictly* opposed to this confusing message.

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> I think compressing the release cadence to less than 4 weeks (which is
matt> implied by your suggestion) is overly ambitious and could be setting
matt> ourselves up to fail. If you want to bring the final release date
matt> earlier then one possibility is to drop the second alpha release, so the
matt> timetable becomes:
matt> 
matt> 23rd January 2018, alpha release 1 (pre1)
matt> 	OpenSSL_1_1_1-stable created (feature freeze)
matt> 	master becomes basis for 1.1.2 or 1.2.0 (TBD)
matt> 20th February 2018, beta release 1 (pre2)
matt> 20th March 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published)
matt> 
matt> Doing it that way still gives us the best part of 2 months to work on
matt> the release criteria (i.e. closing off old issues). Another option is to
matt> relax the release criteria, so we need less time to work on them.

And with this, you're proposing that our release cycle starts with a
beta in practice, no matter what you call it.  I am *brutally* opposed
to this plan.

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