Re: Reports on obsolete Postgres versions

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Banck <mbanck(at)gmx(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, 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-12 10:56:19
Message-ID: D581A853-47E3-4948-95D2-3124E96844FC@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>> but that is far down the page. Do we need to improve this?

> I liked the statement from Laurenz a while ago on his blog
> (paraphrased): "Upgrading to the latest patch release does not require
> application testing or recertification". I am not sure we want to put
> that into the official page (or maybe tone down/qualify it a bit), but I
> think a lot of users stay on older minor versions because they dread
> their internal testing policies.

I think we need a more conservative language since a minor release might fix a
planner bug that someone's app relied on and their plans will be worse after
upgrading. While rare, it can for sure happen so the official wording should
probably avoid such bold claims.

> The other thing that could maybe be made a bit better is the fantastic
> patch release schedule, which however is buried in the "developer
> roadmap". I can see how this was useful years ago, but I think this page
> should be moved to the end-user part of the website, and maybe (also)
> integrated into the support/versioning page?

Fair point.

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2024-03-12 10:57:07 Re: Add bump memory context type and use it for tuplesorts
Previous Message Anthonin Bonnefoy 2024-03-12 10:45:20 Re: POC: Extension for adding distributed tracing - pg_tracing