public inbox for [email protected]
help / color / mirror / Atom feedFrom: Nikolay Samokhvalov <[email protected]>
To: Tom Lane <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Isaac Morland <[email protected]>
Cc: Kirk Wolak <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Rename Postgres 19 to Postgres 26 (year-based)?
Date: Mon, 25 May 2026 15:21:45 -0700
Message-ID: <CAM527d_bY2Rcadq9sUckuVxAysU=kA2GeyG1XfRan1J2VYvDKw@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAM527d9HNDGS4wZBNK8vhRXtRX09i4UwKjvifUvSPS+P-i-1CQ@mail.gmail.com>
<CACLU5mSnxYVf1ZkuZ4VuiREXA_42fe22+fR38y2_JJ6+WJQGyw@mail.gmail.com>
<CAMsGm5fPUwBxgY2RGGzpEp7Sjv7VMU28vcjN+RmuWQpTWM2uRA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
On Sun, May 24, 2026 at 10:04 AM Tom Lane <[email protected]> wrote:
> Peter Eisentraut <[email protected]> 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
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Rename Postgres 19 to Postgres 26 (year-based)?
In-Reply-To: <CAM527d_bY2Rcadq9sUckuVxAysU=kA2GeyG1XfRan1J2VYvDKw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox