[openssl-project] 1.1.1 Release timetable (again)

[Salz, Rich]

As long as we have the freedom to release earlier, this looks okay to me.

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