From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Treat <rob(at)xzilla(dot)net> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Michael Banck <mbanck(at)gmx(dot)net>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Reports on obsolete Postgres versions |
Date: | 2024-03-13 18:21:20 |
Message-ID: | 2074093.1710354080@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Treat <rob(at)xzilla(dot)net> writes:
> On Wed, Mar 13, 2024 at 1:12 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>> On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:
>>> In my view, the best thing would be to move toward consistently using
>>> the word "patch" and moving away from the word "minor" for the
>>> PostgreSQL quarterly maintenance updates.
>> I think "minor" is a better term since it contrasts with "major". We
>> don't actually supply patches to upgrade minor versions.
> 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).
Agreed, we would probably add confusion not reduce it if we were to
change our longstanding nomenclature for this.
I'm +1 on rewriting these documentation pages though. Seems like
they could do with a whole fresh start rather than just tweaks
around the edges --- what we've got now is an accumulation of such
tweaks.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jelte Fennema-Nio | 2024-03-13 18:27:06 | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Previous Message | Jacob Champion | 2024-03-13 18:20:16 | Re: Support json_errdetail in FRONTEND builds |