OpenSSL

Cryptography and SSL/TLS Toolkit

Release Strategy

First issued 23rd December 2014
Last modified 29th May 2018

As of release 1.0.0 the OpenSSL versioning scheme was improved to better meet developers' and vendors' expectations. Letter releases, such as 1.0.2a, exclusively contain bug and security fixes and no new features. Minor releases that change the last digit, e.g. 1.1.0 vs. 1.1.1, can and are likely to contain new features, but in a way that does not break binary compatibility. This means that an application compiled and dynamically linked with 1.1.0 does not need to be recompiled when the shared library is updated to 1.1.1. It should be noted that some features are transparent to the application such as the maximum negotiated TLS version and cipher suites, performance improvements and so on. There is no need to recompile applications to benefit from these features.

With regards to current and future releases the OpenSSL project has adopted the following policy:

  • Version 1.1.0 will be supported until one year after the release of 1.1.1
  • Version 1.0.2 will be supported until 2019-12-31 (LTS).
  • Version 1.0.1 is no longer supported.
  • Version 1.0.0 is no longer supported.
  • Version 0.9.8 is no longer supported.

We may designate a release as a Long Term Support (LTS) release. LTS releases will be supported for at least five years and we will specify one at least every four years. Non-LTS releases will be supported for at least two years.

During the final year of support, we do not commit to anything other than security fixes. Before that, bug and security fixes will be applied as appropriate.

The next version of OpenSSL will be 1.1.1 which will be an LTS release. This is currently in development and has a primary focus of implementing TLSv1.3. The RFC for TLSv1.3 has not yet been published by the IETF. OpenSSL 1.1.1 will not have its final release until that has happened.

The draft release timetable for 1.1.1 is as follows. This may be amended at any time as the need arises.

  • 13th February 2018, alpha release 1 (pre1)
  • 27th February 2018, alpha release 2 (pre2)
  • 20th 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)
  • 3rd April 2018, beta release 2 (pre4)
  • 17th April 2018, beta release 3 (pre5)
  • 1st May 2018, beta release 4 (pre6)
  • 29th May 2018, beta release 5 (pre7)
  • 19th June 2018, beta release 6 (pre8)
  • Release readiness check following pre8 release (new release cycles added if required)

An alpha release means:

  • Not (necessarily) feature complete
  • Not necessarily all new APIs in place yet

A beta release means:

  • Feature complete/Feature freeze (but may include a non-final implementation of the TLSv1.3 specification)
  • Bug fixes only

We have defined the following release criteria for 1.1.1:

  • 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 (with at least one beta release after the publicaction)

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