[openssl-commits] [web] master update

[Rich Salz]

The branch master has been updated
       via  ac5eb58ddc24db122c494b4cb13de3adff366e48 (commit)
      from  2f148d990cb7ada6bf1516d08d9927cc9efd7b26 (commit)


- Log -----------------------------------------------------------------
commit ac5eb58ddc24db122c494b4cb13de3adff366e48
Author: Rich Salz <rsalz at 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 <matt at openssl.org>
    Reviewed-by: Mark Cox <mark at 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>