Today the OpenSSL project published its Release Strategy. You can read it here. There are some really important announcements discussed in it. I’d like to spend a bit of time talking about the thinking that went into writing this strategy.

There are lots of different competing pressures on the project regarding when and how often we should make new releases. At the moment we currently support the following:

• Version 0.9.8
• Version 1.0.0
• Version 1.0.1

Soon we will additionally be supporting version 1.0.2 (I expect the release of that version very early in the New Year). As a development team we are of course also working on our next release - version 1.1.0. So that makes a total of 5 different versions that we have to deal with. That’s quite an overhead for what is in reality a small team. Purely looking at it from a development team perspective we would like to reduce the number of versions that we are supporting so that we can spend our time to better effect (for the benefit of everyone).

At the same time of course many organisations demand stability and an ability to do some long term planning. It can be a non-trivial amount of effort to move an application from one version of the library to the next and we would like to provide sufficient notice and warning to organsiations about how long our releases will be around for, and how long they can expect support to be provided for.

Finally there are constantly new developments that we need to keep up with: new standards to implement; new features requested by users; refactoring and other improvments to the library codebase and so on. We would like to be able to make those features available to users more quickly…i.e. we would like to increase the pace of our releases, so that new features are not sat within our development branch for extended periods without the opportunity for users to benefit from them.

So how do we release more frequently, whilst supporting less concurrent versions and give organisations and users some long term stability? The Release Strategy is our attempt at balancing these various competing needs.

Back in October we announced the End Of Life of version 0.9.8. This version is currently only receiving security updates, and support will cease completely on 31st December 2015. Version 0.9.8 has been around for a long time now. It was first released in July 2005. By the time it ceases to receive security updates it will have been around for over 10 years. Frankly, it is time to say goodbye to it. Today we are additionally announcing the End Of Life of version 1.0.0. Again, this version will be receiving security updates only for the next year and support will also cease completely on 31st December 2015. Version 1.0.0 was first released in March 2010. So this version too has had a long lifetime…by the time this version is fully retired it will have been around for over 5 years.

These two announcements help us as a development team to achieve one of our first objectives: reducing the support overhead so that we can better focus our efforts.

We also want to be able to provide our users with forward planning information, so we have given a date that we plan to cease support for version 1.0.1. For the next year version 1.0.1 will continue to receive full support. After that it will receive one further year of security fixes only. Version 1.0.2 will receive support for at least as long as this - and possibly longer. We are aiming to introduce the concept of a Long Term Support (LTS) release in the future. We are not at this time nominating a release to be an LTS. This will certainly be from the 1.0.x series. Whilst at the moment we are not planning a version 1.0.3, there is an outside chance that we will need one. If one is introduced then that will become the LTS release, otherwise it will be 1.0.2. The LTS release will receive support for a period of five years.

This we hope will give our users the stability and forward planning information that they need.

The LTS release concept helps us to achieve our final aim - release more frequently. By giving those users who need stability a release that they can rely on for the long term, this frees us up to provide more releases with a shorter lifespan - enabling new features and capabilities to get into live usage more quickly. Users of these releases should expect to have to upgrade more often than historically has been the case - but our aim is to tell you up front how long the release will be around for.

I’ve left the most exciting item in our Release Strategy until last - version 1.1.0. I expect us to be talking a lot more over the coming months about what you can expect to see in this release. The middle version number has been incremented, which means you should expect to see some API incompatibilities between the 1.0.x releases and this one. You can already see some of that in the git master branch. The bn sub-library API has been made opaque, so that internal structures and details have been removed from the public header files. Similar work will be done to the rest of the library. This is much needed work. Our Roadmap talked about our objective to reduce library complexity. In the past we have been hampered by the requirement to provide a stable API. Since many of the internal details effectively formed part of that API it meant that we could not perform a lot of the refactoring work that we would like to be able to do to simplify things. By removing those internal details this frees us up to achieve our objective.

We are hoping to have a version 1.1.0 release at the end of next year, with a preview release in the middle of the year.