Release Strategy

First issued 23 December 2014

Last modified 25 June 2025

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 that will be supported for at least 5 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.

Starting with 3.5, we plan to designate an LTS every two years. In essence that means an LTS will be released every April in odd-numbered years. Therefore there will always be two fully supported LTS releases.

Non-LTS releases up to 3.4 are supported for at least two years. Non-LTS releases after 3.5 will be full supported for 13 months. Given two releases a year, at least the two latest releases will be fully supported regardless of LTS status.

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: