[openssl-project] 1.1.1 Release timetable (again)

Salz, Rich rsalz at akamai.com
Wed Jan 24 19:12:27 UTC 2018


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.


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
    



More information about the openssl-project mailing list