[openssl-project] 1.1.1 Release timetable (again)

[Matt Caswell]

On 25/01/18 19:08, Matt Caswell wrote:
> 
> 
> 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.

I've had several approvals and no objections on this PR so I think we
should go ahead with a vote. My proposed vote text is:

"We should update the release strategy as shown in
https://github.com/openssl/web/pull/41, commit id 52d9ea8fb"

Any objections to the wording before I raise this?

Matt

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