Re: Rename Postgres 19 to Postgres 26 (year-based)?

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Isaac Morland <isaac(dot)morland(at)gmail(dot)com>
Cc: Kirk Wolak <wolakk(at)gmail(dot)com>, Nikolay Samokhvalov <nik(at)postgres(dot)ai>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Rename Postgres 19 to Postgres 26 (year-based)?
Date: 2026-05-24 14:22:47
Message-ID: 0e41a002-ec9d-4acd-bb2c-3104c12607e3@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22.05.26 08:54, Tom Lane wrote:
> Isaac Morland <isaac(dot)morland(at)gmail(dot)com> writes:
>> I like this because it makes it very clear that there has been a change in
>> numbering scheme. Skipping 7 numbers could be due to almost anything, in
>> the long term, but no one will think PG2026 is just 2008 versions after
>> PG18. Also, I agree that while most likely no one on this list will be
>> worrying about this in 2100, it would be nice to know that nobody has to
>> worry about what comes after PG99.
>
> Geez, I thought we were permanently done with what-shall-we-call-
> the-next-release threads after we dropped three-part version numbers.
>
> I don't like either version of this proposal, because I fear it
> puts way too much faith in our ability to adhere to a fixed release
> calendar. What happens if "v2027" slips into 2028? Are we then
> unable to resume the normal schedule for the following release?

Furthermore, some things that release toward the end of year N are
released as version N+1, for marketing reasons. So this approach
wouldn't even really reduce ambiguity or the need for more arguing.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-05-24 17:03:59 Re: Rename Postgres 19 to Postgres 26 (year-based)?
Previous Message Álvaro Herrera 2026-05-24 11:35:59 Re: splitting pg_resetwal output strings