Release Strategy

First issued 23rd December 2014 Last modified 30th November 2023

From 3.0.0 and above, the OpenSSL versioning scheme uses the format: MAJOR.MINOR.PATCH

With this format, API/ABI compatibility will be guaranteed for the same MAJOR version number.

This approximately aligns with the expectations of users who are familiar with semantic versioning. However, we have not adopted semantic versioning in the strict sense of its rules, because it would mean changing our current LTS policies and practices.

For version 1.1.1 and before, the old versioning scheme is used:

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

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 addition of new platforms to LTS branches is acceptable so long as the required changes consist solely of additions to configuration.

Before a major release, we make a number of pre-releases, labeled alpha and beta.

An alpha release means:

A beta release means:

For any major or minor release, we have defined the following release criteria:

Valid reasons for closing an issue/PR with a milestone for the version might be:

No API or ABI breaking changes are allowed in a minor or patch release. The following stability rules apply to all changes made to code targeted for a major release from version 3.0.0 or later: