On 4/12/24 2:12 PM, Bruce Momjian wrote:
I am ready to apply this patch to the website. How do I do this? Do I
just commit this to the pgweb git tree? Does that push to the website?
I pushed this to the website[1].
Thanks,
Jonathan
[1] https://www.postgresql.org/support/versioning/
On Thu, Apr 4, 2024 at 04:51:50PM -0400, Bruce Momjian wrote:
> On Thu, Apr 4, 2024 at 04:38:10PM -0400, Greg Sabino Mullane wrote:
> > On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> > +Such upgrades might require manual changes to complete so always read
> > +the release notes
On Thu, Apr 4, 2024 at 04:38:10PM -0400, Greg Sabino Mullane wrote:
> On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> +Such upgrades might require manual changes to complete so always read
> +the release notes first.
>
> Proposal:
> "Such upgrades might require additional steps,
On Thu, Apr 4, 2024 at 2:23 PM Bruce Momjian wrote:
> -end-of-life (EOL) and no longer supported.
> +after its initial release. After this, a final minor version will be
> released
> +and the software will then be unsupported (end-of-life).
Would be a shame to lose the EOL acronym.
+Such
On Thu, Apr 4, 2024 at 12:27:32PM -0700, David G. Johnston wrote:
> How about this:
> """
> Major versions make complex changes, so the contents of the data directory
> cannot be maintained in a backward compatible way. A dump and restore of the
> databases is required, either done manually or
On Thu, Apr 4, 2024 at 11:23 AM Bruce Momjian wrote:
> On Wed, Apr 3, 2024 at 06:01:41PM -0700, David G. Johnston wrote:
> >
> > The PostgreSQL Global Development Group supports a major version for 5
> years
> > -after its initial release. After its five year anniversary, a major
> version
>
On Wed, Apr 3, 2024 at 06:01:41PM -0700, David G. Johnston wrote:
>
> 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
On Tue, Apr 2, 2024 at 1:47 PM Bruce Momjian wrote:
> On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote:
>
> Okay, I changed "superseded" to "old", and changed "latest" to
> "current", patch attached.
>
>
I took a pass at this and found a few items of note. Changes on top of
> On 2 Apr 2024, at 22:46, Bruce Momjian wrote:
> On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote:
>> 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
On Tue, Apr 2, 2024 at 11:34:46AM +0200, Magnus Hagander wrote:
> On Tue, Apr 2, 2024 at 9:24 AM Daniel Gustafsson wrote:
> A few small comments:
>
> +considers performing minor upgrades to be less risky than continuing to
> +run superseded minor versions.
>
> I think
On Tue, Apr 2, 2024 at 9:24 AM Daniel Gustafsson wrote:
> > On 2 Apr 2024, at 00:56, Bruce Momjian wrote:
>
> > 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
On Wed, Mar 13, 2024 at 7:47 PM Jeremy Schneider
wrote:
>
> > On Mar 13, 2024, at 11:39 AM, Tom Lane wrote:
> >
> > Jeremy Schneider writes:
> >>> On 3/13/24 11:21 AM, Tom Lane wrote:
> >>> Agreed, we would probably add confusion not reduce it if we were to
> >>> change our longstanding
> On 2 Apr 2024, at 00:56, Bruce Momjian wrote:
> 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.
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
On 3/15/24 3:17 AM, Daniel Gustafsson wrote:
>> On 14 Mar 2024, at 16:48, Peter Eisentraut wrote:
>> On 13.03.24 18:12, Bruce Momjian wrote:
>
>>> I think "minor" is a better term since it contrasts with "major". We
>>> don't actually supply patches to upgrade minor versions.
>>
>> There are
On Fri, Mar 15, 2024 at 11:17:53AM +0100, Daniel Gustafsson wrote:
> > On 14 Mar 2024, at 16:48, Peter Eisentraut wrote:
> > One could instead, for example, describe those as "maintenance releases":
>
> That might indeed be a better name for what we provide.
+1
> On 14 Mar 2024, at 16:48, Peter Eisentraut wrote:
> On 13.03.24 18:12, Bruce Momjian wrote:
>> I think "minor" is a better term since it contrasts with "major". We
>> don't actually supply patches to upgrade minor versions.
>
> There are potentially different adjectives that could apply to
On Thu, Mar 14, 2024 at 10:46:28PM -0400, Bruce Momjian wrote:
> > In the end, while I certainly don't mind improving the web page, I
> > think that a lot of what we're seeing here probably has to do with the
> > growing popularity and success of PostgreSQL. If you have more people
> > using your
On Thu, Mar 14, 2024 at 10:15:18AM -0400, Robert Haas wrote:
> I think that whatever we say here should focus on what we try to do or
> guarantee, not on what actions we think users ought to take, never
> mind must take. We can say that we try to avoid making any changes
> upon which an
On 13.03.24 18:12, Bruce Momjian wrote:
On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:
It's not just roadmaps and release pages where we mix up these terms
either, it's even in user-facing SQL and libpq routines: both
PQserverVersion and current_setting('server_version_num')
On Wed, Mar 13, 2024 at 3:05 PM Laurenz Albe wrote:
> I think we are pretty conservative with backpatching changes to the
> optimizer that could destabilize existing plans.
We have gotten better about that, which is good.
> I feel quite strongly that we should not use overly conservative
On Tue, 2024-03-12 at 11:56 +0100, Daniel Gustafsson wrote:
> > 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
On Wed, Mar 13, 2024 at 02:21:20PM -0400, Tom Lane wrote:
> 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.
If no one else volunteers,
> On Mar 13, 2024, at 11:39 AM, Tom Lane wrote:
>
> Jeremy Schneider writes:
>>> On 3/13/24 11:21 AM, Tom Lane wrote:
>>> Agreed, we would probably add confusion not reduce it if we were to
>>> change our longstanding nomenclature for this.
>
>> Before v10, the quarterly maintenance updates
Jeremy Schneider writes:
> On 3/13/24 11:21 AM, Tom Lane wrote:
>> Agreed, we would probably add confusion not reduce it if we were to
>> change our longstanding nomenclature for this.
> Before v10, the quarterly maintenance updates were unambiguously and
> always called patch releases
I think
uarterly maintenance updates were unambiguously and
always called patch releases
I don't understand the line of thinking here
Bruce started this whole thread because of "an increasing number of
bug/problem reports on obsolete Postgres versions"
Across the industry the word "minor" oft
Robert Treat writes:
> On Wed, Mar 13, 2024 at 1:12 PM Bruce Momjian 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
>>>
On Wed, Mar 13, 2024 at 1:12 PM Bruce Momjian wrote:
>
> On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:
> > It's not just roadmaps and release pages where we mix up these terms
> > either, it's even in user-facing SQL and libpq routines: both
> > PQserverVersion and
On Wed, Mar 13, 2024 at 09:21:27AM -0700, Jeremy Schneider wrote:
> It's not just roadmaps and release pages where we mix up these terms
> either, it's even in user-facing SQL and libpq routines: both
> PQserverVersion and current_setting('server_version_num') return the
> patch release version in
On 3/12/24 3:56 AM, Daniel Gustafsson wrote:
>>> 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
>> 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
Hi,
On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:
> On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
> > On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> > > https://www.postgresql.org/support/versioning/
> > >
> > > This web page should correct
> On 12 Mar 2024, at 02:37, Nathan Bossart wrote:
>
> On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:
>> On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
>>> I've read that the use of the term "minor release" can be confusing. While
>>> the versioning page clearly
On Mon, Mar 11, 2024 at 05:17:13PM -0400, Bruce Momjian wrote:
> On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
>> I've read that the use of the term "minor release" can be confusing. While
>> the versioning page clearly describes what is eligible for a minor release,
>> not
On Mon, Mar 11, 2024 at 4:38 PM Bruce Momjian wrote:
> https://www.postgresql.org/support/versioning/
>
> This web page should correct the idea that "upgrades are more risky than
> staying with existing versions". Is there more we can do? Should we have
> a more consistent response for
On Mon, Mar 11, 2024 at 04:12:04PM -0500, Nathan Bossart wrote:
> On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> > https://www.postgresql.org/support/versioning/
> >
> > This web page should correct the idea that "upgrades are more risky than
> > staying with existing
On Mon, Mar 11, 2024 at 04:37:49PM -0400, Bruce Momjian wrote:
> https://www.postgresql.org/support/versioning/
>
> This web page should correct the idea that "upgrades are more risky than
> staying with existing versions". Is there more we can do? Should we
> have a more consistent
I am seeing an increasing number of bug/problem reports on obsolete
Postgres versions, either not running a superseded minor version, or
running an unsupported major version.
What can we do to reduce such reports, or at least give a consistent
response? It is very helpful that we have this web
38 matches
Mail list logo
