[openssl-project] 1.1.1 Release timetable (again)

[Matt Caswell]

On 24/01/18 19:12, Salz, Rich wrote:
> A monthly release cadence for beta seems too long.  I would prefer two weeks.  And we keep doing that until TLS 1.3 is published.

That might be ok. As a technical issue though we can only have a maximum
of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
in opensslv.h). If we were to do a release every 2 weeks starting on
14th Feb, that would mean the last beta we could possibly do would be on
15th August.  If there is a risk that the TLSv1.3 publication could go
beyond that date then we would be stuck.

Matt

> 
> 
> On 1/24/18, 12:32 PM, "Matt Caswell" <matt at openssl.org> wrote:
> 
>     Reviving the 1.1.1 release timetable discussion now that we have a
>     clearer idea of the scope of outstanding issues/PRs.
>     
>     Here is my updated straw man proposal for the 1.1.1 release timetable.
>     The only changes to this from my original proposal is to shift the dates
>     (because in my original proposal we would already have done the first
>     alpha) and I have relabelled the second release as a "beta". My original
>     plan called this an alpha with feature freeze at the same time, which
>     people (vehemently) objected to. :-)
>     
>     14th February 2018, alpha release 1 (pre1)
>     14th March 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)
>     11th March 2018, beta release 2 (pre3)
>     9th May 2018, 1.1.1 public release (assuming TLSv1.3 RFC is published)
>     
>     An alpha release means:
>     - Not (necessarily) feature complete
>     - Not necessarily all new APIs in place yet
>     
>     A beta release means:
>     - Feature complete/Feature freeze
>     - Bug fixes only
>     
>     My proposed release criteria are:
>     - All open github issues/PRs older than 2 weeks at the time of release
>     to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
>     milestone to be closed (see below)
>     - Clean builds in Travis and Appveyor for two days
>     - run-checker.sh to be showing as clean 2 days before release
>     - No open Coverity issues (not flagged as "False Positive" or "Ignore")
>     - TLSv1.3 RFC published
>     
>     Valid reasons for closing an issue/PR with a 1.1.1 milestone might be:
>     - We have just now or sometime in the past fixed the issue
>     - Unable to reproduce (following discussion with original reporter if
>     possible)
>     - Working as intended
>     - Deliberate decision not to fix until a later release (this wouldn't
>     actually close the issue/PR but change the milestone instead)
>     - Not enough information and unable to contact reporter
>     - etc
>     
>     This plan gives us 2 months from feature freeze to get all issues and
>     PRs with the 1.1.1 milestone closed (or assigned to a different
>     milestone). Currently this stands at 141 issues and 55 PRs. In practice
>     I think the only way we get through that lot is to make explicit
>     decisions not to fix/implement some of them and change the milestone.
>     But I think making explicit decisions about these rather than just
>     letting them drift indefinitely is a good thing.
>     
>     If the TLSv1.3 RFC is not published by the time we are ready to release,
>     or we haven't made the progress we want on the other release criteria
>     then we can add additional betas as we see fit until such time as we are
>     ready.
>     
>     Matt
>     _______________________________________________
>     openssl-project mailing list
>     openssl-project at openssl.org
>     https://mta.openssl.org/mailman/listinfo/openssl-project
>     
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project at openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
>