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
