From a5cacdf76f25f3480505cd1c31ecd111b846d4d9 Mon Sep 17 00:00:00 2001 From: "Jonathan S. Katz" Date: Wed, 12 Sep 2018 13:26:57 -0400 Subject: [PATCH] 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. --- templates/support/versioning.html | 71 +++++++++++++++++++++++++++------------ 1 file changed, 49 insertions(+), 22 deletions(-) diff --git a/templates/support/versioning.html b/templates/support/versioning.html index ea91d12..11171e0 100644 --- a/templates/support/versioning.html +++ b/templates/support/versioning.html @@ -5,54 +5,81 @@

Versioning policy

-We always recommend that all users run the latest available minor release for whatever major version is in use. +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, security fixes that are released every three months in what we call a +"minor release." For more information on the minor release schedule, you can +view the minor release roadmap. +

+ +

+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.

-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. +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.

-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 pg_upgrade module is required for major upgrades. +We always recommend that all users run the latest available minor release for whatever major version is in use.

+

Version Numbering

+

-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, security, and data corruption bugs to reduce the risk associated with upgrading. The community considers not upgrading to be riskier than upgrading. +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.

-A tentative schedule for upcoming minor releases can be found in the -roadmap. +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.

+

Upgrading

+

-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. + + We always recommend that all users run the latest available minor + release for whatever major version is in use. +

-

PostgreSQL release support policy

-The PostgreSQL Global Development Group aims to support a major release for -five years. After its end-of-life (EOL) month ends, a major version receives one final minor release. 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 +pg_upgrade module is required +for major upgrades. We also recommend reading the +upgrading section of the major +version you are planning to upgrade to.

-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.

-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, security +issues, and data corruption problems to reduce the risk associated with +upgrading. For minor releases, the community considers not upgrading to be +riskier than upgrading.

-

Release History & EOL Months

+

Release History

-- 2.14.3 (Apple Git-98)