[openssl-project] 1.1.1 Release timetable

[Tim Hudson]

I think Richard meant to state vehemently rather than brutally ...

Tim.

On Sat, Dec 23, 2017 at 4:43 AM, Richard Levitte <levitte at openssl.org>
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.
>
> 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/
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20171223/dc715239/attachment.html>