[openssl-project] 1.1.1 Release timetable (again)

Tue Jan 30 10:45:47 UTC 2018

On 29/01/18 11:04, Matt Caswell wrote:
> 
> 
> 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?

No feedback so I started the vote:

topic: We should update the release strategy as shown in
https://github.com/openssl/web/pull/41, commit id 52d9ea8fb
Proposed by Matt Caswell
Public: yes
opened:	2018-01-30
closed: yyyy-mm-dd
ONE WEEK VOTE

I will report back here with the result once the vote is complete.

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