[openssl-project] 1.1.1 Release timetable (again)

[Matt Caswell]

On 25/01/18 11:59, Salz, Rich wrote:
> As long as we have the freedom to release earlier, this looks okay to me.

I added this sentence to make that freedom crystal clear:

"This may be amended at any time as the need arises"

I have taken this proposal and made it into a PR for updating the
release strategy. The PR is here:

https://github.com/openssl/web/pull/41

Please provide any review comments there. Once any reviews seem to have
settled down to a consensus I will propose an OMC vote.

Matt



> 
> On 1/25/18, 6:00 AM, "Matt Caswell" <matt at openssl.org> wrote:
> 
>     
>     
>     On 25/01/18 07:39, Richard Levitte wrote:
>     > In message <a854cb79-3cab-dea2-e29e-76666d97273f at openssl.org> on Wed, 24 Jan 2018 20:48:54 +0000, Matt Caswell <matt at openssl.org> said:
>     > 
>     > matt> On 24/01/18 19:12, Salz, Rich wrote:
>     > matt> > 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.
>     > matt> 
>     > matt> That might be ok. As a technical issue though we can only have a maximum
>     > matt> of 14 alpha/beta releases (due to the format of OPENSSL_VERSION_NUMBER
>     > matt> in opensslv.h). If we were to do a release every 2 weeks starting on
>     > matt> 14th Feb, that would mean the last beta we could possibly do would be on
>     > matt> 15th August.  If there is a risk that the TLSv1.3 publication could go
>     > matt> beyond that date then we would be stuck.
>     > 
>     > This is the first time, as far as I recall, that we've decided to wait
>     > on someone else for our releases, so I'm thinking that we have the
>     > freedom to decide how to act if there's a delay, for example to delay
>     > our own beta cycle.  It shouldn't be too hard to write a kind of
>     > "caveat emptor" where we say that "should the TLSv1.3 publication be
>     > delayed, we till re-evaluate our plans".
>     > 
>     > (another way to do it is to refuse making a release plan before we
>     > receive a clear signal that publication *will* happen and when it
>     > will...  after all, we *are* putting ourselves in a kind of hostage
>     > situation)
>     
>     Absolutely. As I said in the email that started this thread part of the
>     release criteria include:
>     
>     - TLSv1.3 RFC published
>     
>     And then I later said:
>     
>     "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."
>     
>     A two week release cadence might look like this:
>     
>     13th February 2018, alpha release 1 (pre1)
>     27th February 2018, alpha release 2 (pre2)
>     13th March 2018, beta release 1 (pre3)
>     	OpenSSL_1_1_1-stable created (feature freeze)
>     	master becomes basis for 1.1.2 or 1.2.0 (TBD)
>     27th March 2018, beta release 2 (pre4)
>     10th April 2018, beta release 3 (pre5)
>     24th April 2018, beta release 4 (pre6)
>     1st May 2018, release readiness check (new release cycles added if
>     required, first possible final release date: 8th May 2018)
>     
>     Instead of putting the final release date into the plan (which would
>     have been 8th May), I have put the the final step as a "release
>     readiness check", 1 week after beta4. This puts an explicit opportunity
>     for us to see how we are doing against the criteria. If we are ready
>     then we could push ahead for an 8th May release, otherwise we extend it
>     out as needed.
>     
>     This plan uses up 6 of our maximum possible 14 pre-releases. If we go
>     with this approach and we get to the release readiness check without an
>     RFC then we should probably slow down our release cadence at that point.
>     
>     
>     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
>