policies/releasestrat.html

   1 <!DOCTYPE html>
   2 <html lang="en">
   3 <!--#include virtual="/inc/head.shtml" -->
   4
   5 <body>
   6 <!--#include virtual="/inc/banner.shtml" -->
   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 7th January 2020
  17           </h5>
  18         </header>
  19
  20         <div class="entry-content">
  21
  22           <p>
  23             As of release 3.0.0, the OpenSSL versioning scheme is changing
  24             to a more contemporary format: MAJOR.MINOR.PATCH
  25           </p>
  26
  27           <p>
  28             With this format, API/ABI compatibility will be guaranteed
  29             for the same MAJOR version number. Previously we guaranteed
  30             API/ABI compatibility across the same MAJOR.MINOR combination.
  31           </p>
  32
  33           <ul>
  34             <li>MAJOR: API/ABI incompatible changes will increase this number</li>
  35             <li>MINOR: API/ABI compatible feature releases will change this</li>
  36             <li>PATCH: Bug fix releases will increment this number. We also
  37             allow backporting of accessor functions in these releases.</li>
  38           </ul>
  39
  40           <p>
  41             This more closely aligns with the expectations of users who are
  42             familiar with semantic versioning.  However, we have not adopted
  43             semantic versioning in the strict sense of its rules, because it
  44             would mean changing our current LTS policies and practices.
  45           </p>
  46
  47           <p>
  48             The current 1.1.1 versioning scheme remains unchanged:
  49
  50             <blockquote><i>
  51               As of release 1.0.0 the OpenSSL versioning scheme was improved
  52               to better meet developers' and vendors' expectations. Letter
  53               releases, such as 1.0.2a, exclusively contain bug and security
  54               fixes and no new features. Releases that change the last digit,
  55               e.g. 1.1.0 vs. 1.1.1, can and are likely to
  56               contain new features, but in a way that does not break binary
  57               compatibility. This means that an application compiled and
  58               dynamically linked with 1.1.0 does not need to be recompiled
  59               when the shared library is updated to 1.1.1. It should be
  60               noted that some features are transparent to the application
  61               such as the maximum negotiated TLS version and cipher suites,
  62               performance improvements and so on. There is no need to
  63               recompile applications to benefit from these features.
  64             </i></blockquote>
  65           </p>
  66
  67           <hr />
  68
  69           <p>With regards to current and future releases the OpenSSL
  70           project has adopted the following policy:</p>
  71
  72           <ul>
  73             <li>The next version of OpenSSL will be 3.0.0.</li>
  74             <li>Version 1.1.1 will be supported until 2023-09-11 (LTS).</li>
  75             <li>Version 1.0.2 is no longer supported. Extended support
  76             for 1.0.2 to gain access to security fixes for that version is
  77             <a href="/support/contracts.html">available</a>.</li>
  78             <li>Versions 1.1.0, 1.0.1, 1.0.0 and 0.9.8 are no longer supported.</li>
  79           </ul>
  80
  81           <p>We may designate a release as a Long Term Support (LTS)
  82           release. LTS releases will be supported for at least five years
  83           and we will specify one at least every four years. Non-LTS
  84           releases will be supported for at least two years.</p>
  85
  86           <p>During the final year
  87           of support, we do not commit to anything other than security
  88           fixes. Before that, bug and security fixes will be applied
  89           as appropriate.</p>
  90
  91           <hr />
  92
  93           <p>
  94             Before a major release, we make a number of pre-releases, labeled
  95             <i>alpha</i> and <i>beta</i>.
  96           </p>
  97
  98           <p>An <i>alpha</i> release means:</p>
  99           <ul>
 100             <li>Not (necessarily) feature complete</li>
 101             <li>Not necessarily all new APIs in place yet</li>
 102           </ul>
 103
 104           <p>A <i>beta</i> release means:</p>
 105           <ul>
 106             <li>Feature complete/Feature freeze</li>
 107             <li>Bug fixes only</li>
 108           </ul>
 109
 110           <p>The OpenSSL 3.0 release schedule is documented on the
 111           <a href="https://wiki.openssl.org/index.php/OpenSSL_3.0_Release_Schedule">OpenSSL 3.0 Release Schedule</a>
 112           wiki page. We expect the final release to be in early Q4 2020.</p>
 113
 114           <p>
 115             For any major or minor release, we have defined the following
 116             release criteria:
 117           </p>
 118
 119           <ul>
 120             <li>
 121               All open github issues/PRs older than 2 weeks at the time of
 122               release need to be assessed for relevance to the version being
 123               released. Any flagged with the a milestone for the version
 124               to be released must be closed (see below).
 125             </li>
 126             <li>
 127               Clean builds in Travis and Appveyor for two days.
 128             </li>
 129             <li>
 130               run-checker.sh succeeds on 2 consecutive days before release.
 131             </li>
 132             <li>
 133               No open Coverity issues (not flagged as "False Positive" or
 134               "Ignore").
 135             </li>
 136           </ul>
 137
 138           <p>
 139             Valid reasons for closing an issue/PR with a milestone for the
 140             version might be:
 141           </p>
 142
 143           <ul>
 144             <li>
 145               We have just now or sometime in the past fixed the issue
 146             </li>
 147             <li>
 148               Unable to reproduce (following discussion with original reporter
 149               if possible)
 150             </li>
 151             <li>
 152               Working as intended
 153             </li>
 154             <li>
 155               Deliberate decision not to fix this issue until a later release (this
 156               wouldn't actually close the issue/PR but change the milestone
 157               instead)
 158             </li>
 159             <li>
 160               Not enough information and unable to contact reporter
 161             </li>
 162           </ul>
 163
 164           <hr />
 165
 166           <p>No API or ABI breaking changes are allowed in a minor or patch release.
 167           The following stability rules apply to all changes made to code
 168           targeted for a major release from version 3.0.0 or later:</p>
 169           <ul>
 170             <li>No existing public interface can be modified except where changes
 171             are unlikely to break source compatibility or where structures are made
 172             opaque.
 173             <li>No existing public interface can be removed until its replacement
 174             has been in place in an LTS stable release. The original interface must
 175             also have been documented as deprecated for at least 5 years. A public
 176             interface is any function, structure or macro declared in a public
 177             header file.</li>
 178             <li>When structures are made opaque, any newly required accessor
 179             macros or functions are added in a feature release of the extant LTS
 180             release and all supported intermediate successor releases.</li>
 181           </ul>
 182
 183         </div>
 184         <footer>
 185           You are here: <a href="/">Home</a>
 186           : <a href="/policies">Policies</a>
 187           : <a href="">Release Strategy</a>
 188           <br/><a href="/sitemap.txt">Sitemap</a>
 189         </footer>
 190       </article>
 191     </div>
 192     <!--#include virtual="sidebar.shtml" -->
 193   </div>
 194 </div>
 195
 196 <!--#include virtual="/inc/footer.shtml" -->
 197 </body>
 198
 199 </html>
 200