From fd9452da42ac755ce5a9d6df1aed344cc61d5c0f Mon Sep 17 00:00:00 2001 From: Matt Caswell Date: Tue, 23 Dec 2014 22:49:56 +0000 Subject: [PATCH] Add release strategy --- about/.wmlsnb | 1 + about/releasestrat.wml | 67 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 68 insertions(+) create mode 100644 about/releasestrat.wml diff --git a/about/.wmlsnb b/about/.wmlsnb index 743b321..630a28c 100644 --- a/about/.wmlsnb +++ b/about/.wmlsnb @@ -8,6 +8,7 @@ + diff --git a/about/releasestrat.wml b/about/releasestrat.wml new file mode 100644 index 0000000..a25b04b --- /dev/null +++ b/about/releasestrat.wml @@ -0,0 +1,67 @@ + +#use wml::openssl area=about page=releasestrat + +About, Release Strategy +

OpenSSL Release Strategy

+

First issued 23rd December 2014

+

Last modified 23rd December 2014

+

+
+

+

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:

+ +
    +

  • Support for version 0.9.8 will cease on 2015-12-31. No further releases of 0.9.8 +will be made after that date. Security fixes only will be applied to 0.9.8 until +then.

    • + +

  • Support for version 1.0.0 will cease on 2015-12-31. No further releases of 1.0.0 +will be made after that date. Security fixes only will be applied to 1.0.0 until +then.

    • +
+ +

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.

+ +
    +

  • Version 1.0.1 will be supported until 2016-12-31.

    • + +

  • Version 1.0.2 will be supported until at least 2016-12-31.

    • +
+ +

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). We expect a preview version to be available +mid 2015, with an expected release by the end of 2015. Preview means that we are +not planning or expecting major API changes between the preview release and the +final release (but are not categorically precluding that possibility).

-- 2.34.1