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.1a, exclusively contain bug and security fixes and no new features. Minor releases that change the last digit, e.g. 1.0.1 vs. 1.0.2, 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.0.0 does not need to be recompiled when the shared library is updated to 1.0.2. 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.

Binary compatibility also allows other possibilities. For example, consider an application that wishes to utilize a new cipher provided in a specific 1.0.x release, but it is also desirable to maintain the application in a 1.0.0 context. Customarily this would be resolved at compile time resulting in two binary packages targeting different OpenSSL versions. However, depending on the feature, it might be possible to check for its availability at run-time, thus cutting down on the maintenance of multiple binary packages. Admittedly it takes a certain discipline and some extra coding, but we would like to encourage such practice. This is because we want to see later releases being adopted faster, because new features can improve security.

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

• Version 1.1.0 will be supported until 2018-04-30.
• Version 1.0.2 will be supported until 2019-12-31 (LTS).
• Support for version 1.0.1 will cease on 2016-12-31. No further releases of 1.0.1 will be made after that date. Security fixes only will be applied to 1.0.1 until then.
• 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.

As implied by the above paragraphs, 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.

At this time, we are not planning a 1.0.3 release.

Version 1.1.0 will (moderately) break source compatibility (for example we will make most structures opaque etc). Our current plans for the release timetable are:

• 10th December 2015, alpha release 1
• 14th January 2016, alpha release 2
• 11th February 2016, alpha release 3
• 10th March 2016, 1.1.0 beta 1 release
• 14th April 2016, 1.1.0 beta 2 release
• 12th May 2016, 1.1.0 public release

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

Beta 2 release means:

• Opaque work complete