Add release strategy

diff --git a/about/.wmlsnb b/about/.wmlsnb
index 743b321c8c1d2a3fb7bcb6428d50c5cf114d2ae3..630a28c43a0ea79e965c2614c9ef5258d033f914 100644 (file)
--- a/about/.wmlsnb
+++ b/about/.wmlsnb
@@ -8,6 +8,7 @@
   <snb_button id=rt       txt="Bugs"            url="/support/rt.html">
   <snb_button id=roadmap  txt="Roadmap"         url="roadmap.html">
   <snb_button id=secpol   txt="Security Policy" url="secpolicy.html">
+  <snb_button id=releasestrat   txt="Release Strategy" url="releasestrat.html">
   <snb_button id=contacts txt="Contacts"        url="contacts.html">
   <snb_button id=credits  txt="Credits"         url="credits.html">
 </snb>

diff --git a/about/releasestrat.wml b/about/releasestrat.wml
new file mode 100644 (file)
index 0000000..a25b04b
--- /dev/null
+++ b/about/releasestrat.wml
@@ -0,0 +1,67 @@
+
+#use wml::openssl area=about page=releasestrat
+
+<title>About, Release Strategy</title>
+<h1><center>OpenSSL Release Strategy</center></h1>
+<h2><center>First issued 23rd December 2014</center></h2>
+<h2><center>Last modified 23rd December 2014</center></h2>
+<p>
+<br>
+</p>
+<p>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.</p>
+
+<p>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.</p>
+
+<p>With regards to current and future releases the OpenSSL project has adopted the
+following policy:</p>
+
+<ul>
+<li><p>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.</p></li>
+
+<li><p>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.</p></li>
+</ul>
+
+<p>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.</p>
+
+<p>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.</p>
+
+<ul>
+<li><p>Version 1.0.1 will be supported until 2016-12-31.</p></li>
+
+<li><p>Version 1.0.2 will be supported until at least 2016-12-31.</p></li>
+</ul>
+
+<p>At this time, we are not planning a 1.0.3 release.</p>
+
+<p>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).</p>