Back around the end of 2014 we posted our release strategy. This was the first time we defined support timelines for our releases, and added the concept of an LTS (long-term support) release. At our OMC meeting earlier this month, we picked our next LTS release. This post walks through that announcement, and tries to explain all the implications of it.

Once an official release is made, it then enters support mode. No new features are added – those only go into the next release. In rare cases we will make an exception; for example, we said that if any accessors or setters are missing in 1.1.0, because of structures being made opaque, we would treat that as a bug.

Support itself is divided into three phases. First, there is active and ongoing support. All bugs are appropriate for this phase. This happens once the release is published. Next is the security-only phase, where we only fix security bugs, which will typically have a CVE associated with them. This happens for the final year of support. Finally, there is EOL (end of life), where the project no longer provides any support or fixes.

In the typical case, a release is supported for at least two years, which means one year of fixes and one year of security-only fixes. Some releases, however, are designated as LTS releases. They are supported for at least five years. We will specify an LTS release at least every four years, which gives the community at least a year to migrate.

Our current LTS release is 1.0.2, and it will be supported until the end of 2019. During that last year it will only receive security fixes. Although we are extended 1.1.0 support, we explicitly decided not to do it again, for either release.

Our next LTS release will be 1.1.1 which is currently in beta. As long as the release is out before the end of 2018, there is more than a year to migrate. (We’re confident it will be out before then, of course.) We encourage everyone to start porting to the OpenSSL master branch.

The 1.1.0 release will be supported for one year after 1.1.1 is released. And again, during that final year we will only provide security fixes. Fortunately, 1.1.0 is ABI compatible with 1.1.1, so moving up should not be difficult. Our TLS 1.3 wiki page has some more details around the impact of TLS 1.3 support.

Finally, this has an impact on the OpenSSL FIPS module, #1747. That module is valid until the January 29, 2022. This means that for the final two-plus years of its validity, we will not be supporting the release on which the module is based. We have already stated that we do not support the module itself; this adds to the burden that vendors will have to take on. On the positive side, we’re committed to a new FIPS module, it will be based on the current codebase, and we think we can get it done fairly quickly.