Modify version policy language to be more clear about how releases occur.

In essence, a release is supported until its 5 year anniversary, and
will receive one additional set of fixes after that. This is inline
with what we are currently doing, but should help make it more clear.

diff --git a/pgweb/core/models.py b/pgweb/core/models.py
index 80233fea31edbdd8c957cda552009bc5b75df971..95a4cfa8a42345a6dbf9e391b74b92cbc59fe581 100644 (file)
--- a/pgweb/core/models.py
+++ b/pgweb/core/models.py
@@ -23,7 +23,7 @@ class Version(models.Model):
        testing = models.IntegerField(null=False, blank=False, default=0, help_text="Testing level of this release. latestminor indicates beta/rc number", choices=TESTING_CHOICES)
        docsloaded = models.DateTimeField(null=True, blank=True, help_text="The timestamp of the latest docs load. Used to control indexing and info on developer docs.")
        firstreldate = models.DateField(null=False, blank=False, help_text="The date of the .0 release in this tree")
-       eoldate = models.DateField(null=False, blank=False, help_text="The planned EOL date for this tree")
+       eoldate = models.DateField(null=False, blank=False, help_text="The final release date for this tree")
 
        def __unicode__(self):
                return self.versionstring

diff --git a/templates/support/versioning.html b/templates/support/versioning.html
index ea91d1279380d2e18d0352c4ceefb6546ed4697b..25c30f894ced09b58fd55fd016bd2c9534d5e568 100644 (file)
--- a/templates/support/versioning.html
+++ b/templates/support/versioning.html
@@ -5,54 +5,78 @@
 <h1>Versioning policy <i class="fas fa-code-branch"></i></h1>
 
 <p>
-<em>We always recommend that all users run the latest available minor release for whatever major version is in use.</em>
-</p>
+The PostgreSQL Global Development Group releases a new major version containing
+new features about once a year. Each major version receives bug fixes and, if
+need be, <a href="/support/security/">security</a> fixes that are released at
+least once every three months in what we call a "minor release." For more
+information on the minor release schedule, you can view the
+<a href="/developer/roadmap/">minor release roadmap</a>.
+<p>
 
 <p>
-PostgreSQL major releases include new features and occur roughly once every year. Beginning with version 10, a major release is indicated by increasing the first part of the version, e.g. 10 to 11.  Before version 10, a major release was indicated by increasing either the first or second part of the version number, e.g. 9.5 to 9.6.
+If the release team determines that a critical bug or security fix is too
+important to wait until the regularly scheduled minor release, it may make
+a release available outside of the minor release roadmap.
 </p>
 
 <p>
-Major releases usually change the internal format of system tables and data files.  These changes are often complex, so we do not maintain backward compatibility of all stored data.  A dump/reload of the database or use of the <a href="/docs/current/static/pgupgrade.html">pg_upgrade</a> module is required for major upgrades.
+The PostgreSQL Global Development Group supports a major version for 5 years
+after its initial release. After its five year anniversary, a major version will
+have one last minor release containing any fixes and will be considered
+end-of-life (EOL) and no longer supported.
 </p>
 
+<h2>Version Numbering</h2>
+
 <p>
-Minor releases are numbered by increasing the last part of the version number.  Beginning with version 10, this is the second part of the version number, e.g. 10.0 to 10.1; for older versions this is the third part of the version number, e.g. 9.5.3 to 9.5.4. The PostgreSQL team only adds bug fixes to minor releases. All users should upgrade to the most recent minor release as soon as possible. While upgrades always have some risk, PostgreSQL minor releases fix only frequently-encountered, <a href="/support/security/">security</a>, and data corruption bugs to reduce the risk associated with upgrading. <em>The community considers not upgrading to be riskier than upgrading</em>.
+Starting with PostgreSQL 10, a major version is indicated by increasing the
+first part of the version, e.g. 10 to 11.  Before PostgreSQL 10, a major version
+was indicated by increasing either the first or second part of the version
+number, e.g. 9.5 to 9.6.
 </p>
 
 <p>
-A tentative schedule for upcoming minor releases can be found in the
-<a href="/developer/roadmap/">roadmap</a>.
+Minor releases are numbered by increasing the last part of the version number.
+Beginning with PostgreSQL 10, this is the second part of the version number,
+e.g. 10.0 to 10.1; for older versions this is the third part of the version
+number, e.g. 9.5.3 to 9.5.4.
 </p>
 
+<h2>Upgrading</h2>
+
 <p>
-Upgrading to a minor release does not require a dump and restore; merely stop the database server, install the updated binaries, and restart the server.  For some releases, manual changes may be required to complete the upgrade, so always read the release notes before upgrading.
+  <strong>
+    We always recommend that all users run the latest available minor
+    release for whatever major version is in use.
+  </strong>
 </p>
 
-<h2>PostgreSQL release support policy</h2>
 <p>
-The PostgreSQL Global Development Group aims to support a major release for
-<strong>five years</strong>. After its end-of-life (EOL) month ends, a major version receives one final <a href="/developer/roadmap/">minor release</a>. After that final minor release, bug fixing ceases for that major version.
+Major versions usually change the internal format of system tables and data
+files.  These changes are often complex, so we do not maintain backward
+compatibility of all stored data.  A dump/reload of the database or use of the
+<a href="/docs/current/static/pgupgrade.html">pg_upgrade</a> module is required
+for major upgrades. We also recommend reading the
+<a href="/docs/current/static/upgrading.html">upgrading</a> section of the major
+version you are planning to upgrade to.
 </p>
 
 <p>
-After a release falls out of full support, we may (at our committers'
-discretion) continue to apply further critical fixes to the source code,
-on a best-effort basis. No formal releases or binary packages will be
-produced by the project, but the updated source code will be available
-from our source code control system.
+Upgrading to a minor release does not normally require a dump and restore;  you
+can stop the database server, install the updated binaries, and restart the
+server.  For some releases, manual changes may be required to complete the
+upgrade, so always read the release notes before upgrading.
 </p>
 
 <p>
-This policy will be followed on a best-effort basis. In extreme cases it
-may not be possible to support a release for the planned lifetime; for
-example if a serious bug is found that cannot be resolved in a given major
-version without significant risk to the stability of the code or loss of
-application compatibility. In such cases, early retirement of a major
-version may be required.
+While upgrading will always contain some level of risk, PostgreSQL minor releases
+fix only frequently-encountered bugs, <a href="/support/security/">security</a>
+issues, and data corruption problems to reduce the risk associated with
+upgrading. For minor releases, <em>the community considers not upgrading to be
+riskier than upgrading.</em>
 </p>
 
-<h2>Release History &amp; EOL Months</h2>
+<h2>Release History</h2>
 
 <table class="table table-striped">
   <thead class="thead-light">
@@ -60,8 +84,8 @@ version may be required.
       <th>Version</th>
       <th>Current minor</th>
       <th>Supported</th>
-      <th>First release month</th>
-      <th>EOL month</th>
+      <th>First Release</th>
+      <th>Expected Final Release</th>
     </tr>
   </thead>
   <tbody>
@@ -70,8 +94,8 @@ version may be required.
        <td>{{v.numtree}}</td>
        <td>{{v.numtree}}.{{v.latestminor}}</td>
        <td>{{v.supported|yesno:"Yes,No"}}</td>
-       <td>{{v.firstreldate|date:"F Y"}}</td>
-       <td>{{v.eoldate|date:"F Y"}}</td>
+       <td>{{v.firstreldate|date:"F j, Y"}}</td>
+       <td>{{v.eoldate|date:"F j, Y"}}</td>
       </tr>
     {%endfor%}
   </tbody>