| 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.
| 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 |