On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote: > On Tue, Apr 2, 2024 at 9:24 AM Daniel Gustafsson <dan...@yesql.se> wrote: > A few small comments: > > +considers performing minor upgrades to be less risky than continuing to > +run superseded minor versions.</em> > > I think "superseded minor versions" could be unnecessarily complicated for > non-native speakers, I consider myself fairly used to reading english but > still > had to spend a few extra (brain)cycles parsing the meaning of it in this > context. > > + We recommend that users always run the latest minor release associated > > Or perhaps "current minor release" which is the term we use in the table > below > on the same page? > > I do like the term "current" better. It conveys (at least a bit) that we > really consider all the older ones to be, well, obsolete. The difference > "current vs obsolete" is stronger than "latest vs not quite latest".
Okay, I changed "superseded" to "old", and changed "latest" to "current", patch attached. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
diff --git a/templates/support/versioning.html b/templates/support/versioning.html index d48e11e0..0ed79f4f 100644 --- a/templates/support/versioning.html +++ b/templates/support/versioning.html @@ -45,15 +45,8 @@ number, e.g. 9.5.3 to 9.5.4. <h2>Upgrading</h2> <p> - <strong> - We always recommend that all users run the latest available minor - release for whatever major version is in use. - </strong> -</p> - -<p> -Major versions usually change the internal format of system tables and data -files. These changes are often complex, so we do not maintain backward +Major versions usually change the internal format of the system tables. +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/pgupgrade.html">pg_upgrade</a> module is required for major upgrades. We also recommend reading the @@ -65,18 +58,25 @@ versions prior to doing so. </p> <p> -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. +Minor release upgrades do not require a dump and restore; you simply stop +the database server, install the updated binaries, and restart the server. +Such upgrades might require manual changes to complete so always read +the release notes first. </p> <p> -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> +Minor releases only fix frequently-encountered bugs, <a +href="/support/security/">security</a> issues, and data corruption +problems, so such upgrades are very low risk. <em>The community +considers performing minor upgrades to be less risky than continuing to +run an old minor version.</em> +</p> + +<p> + <strong> + We recommend that users always run the current minor release associated + with their major version. + </strong> </p> <h2>Releases</h2>
