The branch master has been updated via ac5eb58ddc24db122c494b4cb13de3adff366e48 (commit) from 2f148d990cb7ada6bf1516d08d9927cc9efd7b26 (commit)
- Log ----------------------------------------------------------------- commit ac5eb58ddc24db122c494b4cb13de3adff366e48 Author: Rich Salz <rs...@akamai.com> Date: Mon May 14 16:29:47 2018 -0400 Remove rationale, clarify language. Add 1.1.1 release/LTS details. Remove paragraph justifying binary compatibility. Also remove phrase "as implied by the above" beause, well, it ACTUALY ISN'T implied by the above. :) Reviewed-by: Matt Caswell <m...@openssl.org> Reviewed-by: Mark Cox <m...@openssl.org> (Merged from https://github.com/openssl/web/pull/52) ----------------------------------------------------------------------- Summary of changes: policies/releasestrat.html | 28 ++++++++-------------------- 1 file changed, 8 insertions(+), 20 deletions(-) diff --git a/policies/releasestrat.html b/policies/releasestrat.html index 3f37936..83b85d2 100644 --- a/policies/releasestrat.html +++ b/policies/releasestrat.html @@ -34,20 +34,6 @@ 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> @@ -64,15 +50,18 @@ 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 + <p>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 + fixes. Before then, 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.</p> + 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> <p>The draft release timetable for 1.1.1 is as follows. This may be amended at any time as the need arises.</p> @@ -88,9 +77,8 @@ <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>8th May 2018, release readiness check (new release - cycles added if required, first possible final release date: - 15th May 2018)</li> + <li>29th May 2018, beta release 5 (pre7)</li> + <li>19th June 2018, beta release 6 (pre8)</li> </ul> <p>An alpha release means:</p> _____ openssl-commits mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-commits