On Wed, Mar 13, 2024 at 02:04:16PM -0400, Robert Treat wrote: > I tend to agree with Bruce, and major/minor seems to be the more > common usage within the industry; iirc, debian, ubuntu, gnome, suse, > and mariadb all use that nomenclature; and ISTR some distro's who > release packaged versions of postgres with custom patches applied (ie > 12.4-2 for postgres 12.4 patchlevel 2). > > BTW, as a reminder, we do have this statement, in bold, in the > "upgrading" section of the versioning page: > "We always recommend that all users run the latest available minor > release for whatever major version is in use." There is actually > several other phrases and wording on that page that could probably be > propagated as replacement language in some of these other areas.
I ended up writing the attached doc patch. I found that some or our text was overly-wordy, causing the impact of what we were trying to say to be lessened. We might want to go farther than this patch, but I think it is an improvement. I also moved the <strong> text to the bottom of the section --- previously, our <strong> wording referenced minor releases, then we talked about major releases, and then minor releases. This gives a more natural flow. -- 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..cee06954 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 superseded minor versions.</em> +</p> + +<p> + <strong> + We recommend that users always run the latest minor release associated + with their major version. + </strong> </p> <h2>Releases</h2>
