[web] master update
Matt Caswell
matt at openssl.org
Wed Feb 27 16:03:59 UTC 2019
The branch master has been updated
via 419c4314952ac1ad9586bb9b767447242bdfca79 (commit)
via 1700dfb97f7690b6656018b271cdddbc5c880f26 (commit)
via 9d38ec2eceeee727e861507a0a71df35f080f981 (commit)
via 19379975053b4f59b8a57fd6f9648c94589acffc (commit)
via 5977b703ae5371458c39208dd5e3ba7257ee18f1 (commit)
from 4b05bbb28879460b203a4c99ed0c70c12c63a265 (commit)
- Log -----------------------------------------------------------------
commit 419c4314952ac1ad9586bb9b767447242bdfca79
Author: Matt Caswell <matt at openssl.org>
Date: Mon Feb 25 16:20:13 2019 +0000
Update the release strategy modification date
Reviewed-by: Richard Levitte <levitte at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/82)
commit 1700dfb97f7690b6656018b271cdddbc5c880f26
Author: Matt Caswell <matt at openssl.org>
Date: Fri Sep 21 14:11:32 2018 +0100
Add a stability policy to the release strategy
Reviewed-by: Richard Levitte <levitte at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/82)
commit 9d38ec2eceeee727e861507a0a71df35f080f981
Author: Richard Levitte <richard at levitte.org>
Date: Sun Jan 13 00:48:43 2019 +0100
Generalise the descriptions of alpha, beta, and release criteria
Reviewed-by: Matt Caswell <matt at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/82)
commit 19379975053b4f59b8a57fd6f9648c94589acffc
Author: Richard Levitte <richard at levitte.org>
Date: Sun Jan 13 00:39:00 2019 +0100
Remove the 1.1.1 time table and add support information
Reviewed-by: Matt Caswell <matt at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/82)
commit 5977b703ae5371458c39208dd5e3ba7257ee18f1
Author: Richard Levitte <richard at levitte.org>
Date: Sun Jan 13 00:31:36 2019 +0100
Release strategy: add text on the 3.0.0 versioning scheme
Reviewed-by: Matt Caswell <matt at openssl.org>
(Merged from https://github.com/openssl/openssl/pull/82)
-----------------------------------------------------------------------
Summary of changes:
policies/releasestrat.html | 181 ++++++++++++++++++++++++++++++---------------
1 file changed, 122 insertions(+), 59 deletions(-)
diff --git a/policies/releasestrat.html b/policies/releasestrat.html
index 0bb80f5..b0d3686 100644
--- a/policies/releasestrat.html
+++ b/policies/releasestrat.html
@@ -13,34 +13,68 @@
<h2>Release Strategy</h2>
<h5>
First issued 23rd December 2014<br/>
- Last modified 29th May 2018
+ Last modified 25th February 2019
</h5>
</header>
<div class="entry-content">
<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.2a, exclusively contain bug and security
- fixes and no new features. Minor releases that change the
- last digit, e.g. 1.1.0 vs. 1.1.1, 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.1.0 does not need to be recompiled
- when the shared library is updated to 1.1.1. 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>
+ As of release 3.0.0, the OpenSSL versioning scheme is changing
+ to a more contemporary format: MAJOR.MINOR.PATCH
+ </p>
+
+ <p>
+ With this format, API/ABI compatibility will be guaranteed
+ for the same MAJOR version number. Previously we guaranteed
+ API/ABI compatibility across the same MAJOR.MINOR combination.
+ </p>
+
+ <ul>
+ <li>MAJOR: API/ABI incompatible changes will increase this number</li>
+ <li>MINOR: API/ABI compatible feature releases will change this</li>
+ <li>PATCH: Bug fix releases will increment this number. We also
+ allow backporting of accessor functions in these releases.</li>
+ </ul>
+
+ <p>
+ This more closely aligns with the expectations of users who are
+ familiar with semantic versioning. However, we have not adopted
+ semantic versioning in the strict sense of its rules, because it
+ would mean changing our current LTS policies and practices.
+ </p>
+
+ <p>
+ The current 1.1.1 and 1.0.2 versioning scheme remains unchanged:
+
+ <blockquote><i>
+ 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.2a, exclusively contain bug and security
+ fixes and no new features. Releases that change the last digit,
+ e.g. 1.1.0 vs. 1.1.1, 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.1.0 does not need to be recompiled
+ when the shared library is updated to 1.1.1. 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.
+ </i></blockquote>
+ </p>
+
+ <hr />
<p>With regards to current and future releases the OpenSSL
project has adopted the following policy:</p>
<ul>
- <li>Version 1.1.0 will be supported until one year after the release of 1.1.1</li>
+ <li>The next version of OpenSSL will be 3.0.0.</li>
+ <li>Version 1.1.1 will be supported until 2023-09-11 (LTS).</li>
+ <li>Version 1.1.0 will be supported until 2019-09-11.</li>
<li>Version 1.0.2 will be supported until 2019-12-31 (LTS).</li>
- <li>Version 1.0.1 is no longer supported.</li>
+ <li>Version 1.0.1 is no longer supported.</li>
<li>Version 1.0.0 is no longer supported.</li>
<li>Version 0.9.8 is no longer supported.</li>
</ul>
@@ -55,65 +89,94 @@
fixes. Before that, bug and security fixes will be applied
as appropriate.</p>
- <p>The next version of OpenSSL will be 1.1.1 which will be an LTS release.
- This is currently in development and has a primary focus of implementing
- TLSv1.3. The RFC for TLSv1.3 has not yet been published by the IETF.
- OpenSSL 1.1.1 will not have its final release until that has happened.</p>
+ <hr />
- <p>The draft release timetable for 1.1.1 is as follows. This may be
- amended at any time as the need arises.</p>
-
- <ul>
- <li>13th February 2018, alpha release 1 (pre1)</li>
- <li>27th February 2018, alpha release 2 (pre2)</li>
- <li>20th March 2018, beta release 1 (pre3)
- <ul>
- <li>OpenSSL_1_1_1-stable created (feature freeze)</li>
- <li>master becomes basis for 1.1.2 or 1.2.0 (TBD)</li>
- </ul>
- <li>3rd April 2018, beta release 2 (pre4)</li>
- <li>17th April 2018, beta release 3 (pre5)</li>
- <li>1st May 2018, beta release 4 (pre6)</li>
- <li>29th May 2018, beta release 5 (pre7)</li>
- <li>19th June 2018, beta release 6 (pre8)</li>
- <li>Release readiness check following pre8 release (new release
- cycles added if required)</li>
- </ul>
+ <p>
+ Before a major release, we make a number of pre-releases, labeled
+ <i>alpha</i> and <i>beta</i>.
+ </p>
- <p>An alpha release means:</p>
+ <p>An <i>alpha</i> release means:</p>
<ul>
<li>Not (necessarily) feature complete</li>
<li>Not necessarily all new APIs in place yet</li>
</ul>
- <p>A beta release means:</p>
+ <p>A <i>beta</i> release means:</p>
<ul>
- <li>Feature complete/Feature freeze (but may include a non-final implementation of the TLSv1.3 specification)</li>
+ <li>Feature complete/Feature freeze</li>
<li>Bug fixes only</li>
</ul>
- <p>We have defined the following release criteria for 1.1.1:</p>
+ <p>
+ For any major or minor release, we have defined the following
+ release criteria:
+ </p>
+
<ul>
- <li>All open github issues/PRs older than 2 weeks at the time of release
- to be assessed for relevance to 1.1.1. Any flagged with the 1.1.1
- milestone to be closed (see below)</li>
- <li>Clean builds in Travis and Appveyor for two days</li>
- <li>run-checker.sh to be showing as clean 2 days before release</li>
- <li>No open Coverity issues (not flagged as "False Positive" or "Ignore")</li>
- <li>TLSv1.3 RFC published (with at least one beta release after the publicaction)</li>
+ <li>
+ All open github issues/PRs older than 2 weeks at the time of
+ release need to be assessed for relevance to the version being
+ released. Any flagged with the a milestone for the version
+ to be released must be closed (see below).
+ </li>
+ <li>
+ Clean builds in Travis and Appveyor for two days.
+ </li>
+ <li>
+ run-checker.sh succeeds on 2 consecutive days before release.
+ </li>
+ <li>
+ No open Coverity issues (not flagged as "False Positive" or
+ "Ignore").
+ </li>
</ul>
- <p>Valid reasons for closing an issue/PR with a 1.1.1 milestone might be:</p>
+ <p>
+ Valid reasons for closing an issue/PR with a milestone for the
+ version might be:
+ </p>
+
<ul>
- <li>We have just now or sometime in the past fixed the issue</li>
- <li>Unable to reproduce (following discussion with original reporter if
- possible)</li>
- <li>Working as intended</li>
- <li>Deliberate decision not to fix until a later release (this wouldn't
- actually close the issue/PR but change the milestone instead)</li>
- <li>Not enough information and unable to contact reporter</li>
- <li>etc</li>
+ <li>
+ We have just now or sometime in the past fixed the issue
+ </li>
+ <li>
+ Unable to reproduce (following discussion with original reporter
+ if possible)
+ </li>
+ <li>
+ Working as intended
+ </li>
+ <li>
+ Deliberate decision not to fix this issue until a later release (this
+ wouldn't actually close the issue/PR but change the milestone
+ instead)
+ </li>
+ <li>
+ Not enough information and unable to contact reporter
+ </li>
</ul>
+
+ <hr />
+
+ <p>No API or ABI breaking changes are allowed in a minor or patch release.
+ The following stability rules apply to all changes made to code
+ targeted for a major release from version 3.0.0 or later:</p>
+ <ul>
+ <li>No existing public interface can be modified except where changes
+ are unlikely to break source compatibility or where structures are made
+ opaque.
+ <li>No existing public interface can be removed until its replacement
+ has been in place in an LTS stable release. The original interface must
+ also have been documented as deprecated for at least 5 years. A public
+ interface is any function, structure or macro declared in a public
+ header file.</li>
+ <li>When structures are made opaque, any newly required accessor
+ macros or functions are added in a feature release of the extant LTS
+ release and all supported intermediate successor releases.</li>
+ </ul>
+
</div>
<footer>
You are here: <a href="/">Home</a>
More information about the openssl-commits
mailing list