The branch master has been updated
via c9f50cbf963b7d9949332c17e614ad0a6e97d431 (commit)
from ac5eb58ddc24db122c494b4cb13de3adff366e48 (commit)
- Log -----------------------------------------------------------------
commit c9f50cbf963b7d9949332c17e614ad0a6e97d431
Author: Rich Salz <rs...@akamai.com>
Date: Wed May 23 19:57:47 2018 -0400
Revert "Remove rationale, clarify language."
This reverts commit ac5eb58ddc24db122c494b4cb13de3adff366e48.
-----------------------------------------------------------------------
Summary of changes:
policies/releasestrat.html | 28 ++++++++++++++++++++--------
1 file changed, 20 insertions(+), 8 deletions(-)
diff --git a/policies/releasestrat.html b/policies/releasestrat.html
index 83b85d2..3f37936 100644
--- a/policies/releasestrat.html
+++ b/policies/releasestrat.html
@@ -34,6 +34,20 @@
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>
@@ -50,18 +64,15 @@
and we will specify one at least every four years. Non-LTS
releases will be supported for at least two years.</p>
- <p>During the final year
+ <p>As implied by the above paragraphs, during the final year
of support, we do not commit to anything other than security
- fixes. Before then, bug and security fixes will be applied
+ fixes. Before that, bug and security fixes will be applied
as appropriate.</p>
<p>The next version of OpenSSL will be 1.1.1. 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;
- we want to have at least one beta release after TLS 1.3 is
- officially published as an RFC. The next LTS release will be
- 1.1.1.</p>
+ will not have its final release until that has happened.</p>
<p>The draft release timetable for 1.1.1 is as follows. This may be
amended at any time as the need arises.</p>
@@ -77,8 +88,9 @@
<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>8th May 2018, release readiness check (new release
+ cycles added if required, first possible final release date:
+ 15th May 2018)</li>
</ul>
<p>An alpha release means:</p>
_____
openssl-commits mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits
