policies/releasestrat.html

   1 <!DOCTYPE html>
   2 <html lang="en">
   3 <!--#include virtual="/inc/head.inc" -->
   4
   5 <body>
   6 <!--#include virtual="/inc/banner.inc" -->
   7
   8 <div id="main">
   9   <div id="content">
  10     <div class="blog-index">
  11       <article>
  12         <header>
  13           <h2>Release Strategy</h2>
  14           <h5>
  15             First issued 23rd December 2014<br/>
  16             Last modified 3rd March 2016
  17           </h5>
  18         </header>
  19
  20         <div class="entry-content">
  21
  22           <p>
  23           As of release 1.0.0 the OpenSSL versioning scheme was improved
  24           to better meet developers' and vendors' expectations. Letter
  25           releases, such as 1.0.1a, exclusively contain bug and security
  26           fixes and no new features. Minor releases that change the
  27           last digit, e.g. 1.0.1 vs. 1.0.2, can and are likely to
  28           contain new features, but in a way that does not break binary
  29           compatibility. This means that an application compiled and
  30           dynamically linked with 1.0.0 does not need to be recompiled
  31           when the shared library is updated to 1.0.2. It should be
  32           noted that some features are transparent to the application
  33           such as the maximum negotiated TLS version and cipher suites,
  34           performance improvements and so on. There is no need to
  35           recompile applications to benefit from these features.</p>
  36
  37           <p>Binary compatibility also allows other possibilities. For
  38           example, consider an application that wishes to utilize
  39           a new cipher provided in a specific 1.0.x release, but it
  40           is also desirable to maintain the application in a 1.0.0
  41           context.  Customarily this would be resolved at compile time
  42           resulting in two binary packages targeting different OpenSSL
  43           versions. However, depending on the feature, it might be
  44           possible to check for its availability at run-time, thus cutting
  45           down on the maintenance of multiple binary packages. Admittedly
  46           it takes a certain discipline and some extra coding, but we
  47           would like to encourage such practice. This is because we
  48           want to see later releases being adopted faster, because new
  49           features can improve security.</p>
  50
  51           <p>With regards to current and future releases the OpenSSL
  52           project has adopted the following policy:</p>
  53
  54           <ul>
  55             <li>Version 1.1.0 will be supported until 2018-04-30.</li>
  56             <li>Version 1.0.2 will be supported until 2019-12-31 (LTS).</li>
  57             <li>Support for version 1.0.1 will cease on 2016-12-31. No
  58             further releases of 1.0.1 will be made after that date.
  59             Security fixes only will be applied to 1.0.1 until then.</li>
  60             <li>Version 1.0.0 is no longer supported.</li>
  61             <li>Version 0.9.8 is no longer supported.</li>
  62           </ul>
  63
  64           <p>We may designate a release as a Long Term Support (LTS)
  65           release. LTS releases will be supported for at least five years
  66           and we will specify one at least every four years. Non-LTS
  67           releases will be supported for at least two years.</p>
  68
  69           <p>As implied by the above paragraphs, during the final year
  70           of support, we do not commit to anything other than security
  71           fixes. Before that, bug and security fixes will be applied
  72           as appropriate.</p>
  73
  74           <p>At this time, we are not planning a 1.0.3 release.</p>
  75
  76           <p>Version 1.1.0 will (moderately) break source compatibility
  77           (for example we will make most structures opaque etc). Our current plans
  78       for the release timetable are:</p>
  79
  80           <ul>
  81             <li>10th December 2015, alpha release 1</li>
  82             <li>14th January 2016, alpha release 2</li>
  83             <li>11th February 2016, alpha release 3</li>
  84             <li>10th March 2016, 1.1.0 beta 1 release</li>
  85             <li>14th April 2016, 1.1.0 beta 2 release</li>
  86             <li>12th May 2016, 1.1.0 public release</li>
  87           </ul>
  88
  89           <p>An alpha release means:</p>
  90
  91           <ul>
  92             <li>Not (necessarily) feature complete</li>
  93             <li>Not necessarily all new APIs in place yet</li>
  94           </ul>
  95
  96           <p>A beta release means:</p>
  97
  98           <ul>
  99             <li>Feature complete/Feature freeze</li>
 100             <li>Bug fixes and cleanup</li>
 101           </ul>
 102
 103           <p>Beta 2 release means:</p>
 104
 105           <ul>
 106             <li>Opaque work complete</li>
 107           </ul>
 108
 109         </div>
 110         <footer>
 111           You are here: <a href="/">Home</a>
 112           : <a href="/policies">Policies</a>
 113           : <a href="">Release Strategy</a>
 114           <br/><a href="/sitemap.txt">Sitemap</a>
 115         </footer>
 116       </article>
 117     </div>
 118     <!--#include virtual="sidebar.inc" -->
 119   </div>
 120 </div>
 121
 122 <!--#include virtual="/inc/footer.inc" -->
 123 </body>
 124
 125 </html>
 126