[openssl-project] 1.1.1 Release timetable

[Matt Caswell]

On 22/12/17 18:43, Richard Levitte wrote:
> 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.

Your way seems even more confusing (to me).

Looking at this from a user's perspective, if we say that a beta release
has no new features and only contains bug fixes, then this implies
"since the last release". Therefore the logical conclusion is that beta
rules apply from the beginning of the development phase for that
release. The development phase for the beta release starts as soon as
the last alpha is done. Therefore the feature freeze should apply from
that point.


> 
> 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.
> 

Well, I am not enthused by this version of the plan either. It was only
put forward as a possible way of achieving Rich's desire for a March
public release. I think my initial plan version with the extra alpha
release is better. I've not yet heard a justification for why we should
be targeting March. If it's to line up with the earliest reasonable date
that we expect the TLS1.3 RFC to be published then that doesn't seem
like a good enough reason to me.

Matt