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

On Sun, May 24, 2026 at 10:04 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Peter Eisentraut <peter(at)eisentraut(dot)org> writes:
> > On 22.05.26 08:54, Tom Lane wrote:
> >> 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.
>
> A different angle came up in the AI-focused unconference session at
> PGConf.dev: somebody speculated that use of AI might accelerate our
> development cycle to the point where it'd be sensible to have two
> major releases per year. I'm not saying I believe that, mind you.
> But it reinforces the point that tying our release numbers to years
> would put undesirable constraints on our release calendar.
>
> regards, tom lane
>

Understood. Thank you both for the direct responses.

The slip risk, the N+1 marketing-renumbering precedent, and the possibility
that cadence may change (biannual or otherwise) -- all make sense.

Year-tied version numbers don't fit. Let me propose something smaller that
still addresses the underlying user problem — knowing at a glance how old a
release is and when it goes EOL.

I have another, much lighter proposal. In fact, two paths:

1) Docs. Add something like "Major version NN released YYYY, EOL Mon YYYY"
explicitly on pages like:

https://www.postgresql.org/docs/
https://www.postgresql.org/docs/release/
https://www.postgresql.org/docs/current/index.html

Today, anyone reasoning about a Postgres version's age has to navigate to
https://www.postgresql.org/support/versioning/ and read the table.
Operators, support engineers, and vendors documenting compatibility do this
constantly. Putting the two dates inline on the docs landing pages removes
that lookup.

2) Annual-release label, alongside the version number. In release
announcements, news posts, and the press kit:

PostgreSQL 19 (2026)

and where prose flows naturally: "PostgreSQL 19, the 2026 annual major
release."

This doesn't tie the version to the year; the integer is still
authoritative. If slippage occurs, it only adjusts the label, and if the
cadence shifts to biannual, it naturally extends to "(2026.1)" / "(2026.2)"
without touching the version number. It's a parallel naming, not a
replacement.

Nik