public inbox for [email protected]
help / color / mirror / Atom feedRename Postgres 19 to Postgres 26 (year-based)?
10+ messages / 8 participants
[nested] [flat]
* Rename Postgres 19 to Postgres 26 (year-based)?
@ 2026-05-21 14:20 Nikolay Samokhvalov <[email protected]>
2026-05-21 15:18 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Junwang Zhao <[email protected]>
2026-05-21 17:44 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Kirk Wolak <[email protected]>
0 siblings, 2 replies; 10+ messages in thread
From: Nikolay Samokhvalov @ 2026-05-21 14:20 UTC (permalink / raw)
To: pgsql-hackers <[email protected]>
I was thinking:
in my mind, Postgres 9.6 was associated with 2016, and "6" at the end of
both the version and the year always helped me memorize the release year.
Memorizing is important when you deal with many databases running different
versions of Postgres – this gives you perspective how old the version is.
And over last 10 years, the release cycle is pretty stable, one major
version per year. So if the upcoming version were 26 instead of 19, and
next year's were 27, it would be easier to understand how current this
version is.
Nik
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Rename Postgres 19 to Postgres 26 (year-based)?
2026-05-21 14:20 Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
@ 2026-05-21 15:18 ` Junwang Zhao <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Junwang Zhao @ 2026-05-21 15:18 UTC (permalink / raw)
To: Nikolay Samokhvalov <[email protected]>; +Cc: pgsql-hackers <[email protected]>
On Thu, May 21, 2026 at 10:20 PM Nikolay Samokhvalov <[email protected]> wrote:
>
> I was thinking:
>
> in my mind, Postgres 9.6 was associated with 2016, and "6" at the end of both the version and the year always helped me memorize the release year.
>
> Memorizing is important when you deal with many databases running different versions of Postgres – this gives you perspective how old the version is.
>
> And over last 10 years, the release cycle is pretty stable, one major version per year. So if the upcoming version were 26 instead of 19, and next year's were 27, it would be easier to understand how current this version is.
Interesting. I think macOS has gone through a similar evolution, macOS
Tahoe (Version 26.5), released in May 2025. We could also give each
major release a name, which sounds pretty interesting to me.
Ubuntu uses a year-based versioning scheme and gives each LTS release
a name, while Debian does not use year-based versions but still
assigns a name to every release.
>
> Nik
--
Regards
Junwang Zhao
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Rename Postgres 19 to Postgres 26 (year-based)?
2026-05-21 14:20 Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
@ 2026-05-21 17:44 ` Kirk Wolak <[email protected]>
2026-05-21 18:45 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Isaac Morland <[email protected]>
1 sibling, 1 reply; 10+ messages in thread
From: Kirk Wolak @ 2026-05-21 17:44 UTC (permalink / raw)
To: Nikolay Samokhvalov <[email protected]>; +Cc: pgsql-hackers <[email protected]>
On Thu, May 21, 2026 at 10:20 AM Nikolay Samokhvalov <[email protected]>
wrote:
> I was thinking:
> ... And over last 10 years, the release cycle is pretty stable, one major
> version per year. So if the upcoming version were 26 instead of 19, and
> next year's were 27, it would be easier to understand how current this
> version is.
>
> Nik
>
+1
There are many reasons I like this. First, it becomes obvious to
EVERYONE how far behind you are in the update cycles.
Right now, if you say you are on PG 12 or PG 17 most non-technical people
have no idea how far behind you are.
From my perspective, I like management asking "It's 2032... Why are we
on PG 28 still?"
The only question it raises is if it should be PG 2026? because in
about 1,000 years it could get confusing.
And I know the PG crowd likes to think ahead...
Kirk Out!
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Rename Postgres 19 to Postgres 26 (year-based)?
2026-05-21 14:20 Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
2026-05-21 17:44 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Kirk Wolak <[email protected]>
@ 2026-05-21 18:45 ` Isaac Morland <[email protected]>
2026-05-22 15:54 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Tom Lane <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Isaac Morland @ 2026-05-21 18:45 UTC (permalink / raw)
To: Kirk Wolak <[email protected]>; +Cc: Nikolay Samokhvalov <[email protected]>; pgsql-hackers <[email protected]>
On Thu, 21 May 2026 at 13:44, Kirk Wolak <[email protected]> wrote:
> From my perspective, I like management asking "It's 2032... Why are we
> on PG 28 still?"
>
> The only question it raises is if it should be PG 2026? because in
> about 1,000 years it could get confusing.
> And I know the PG crowd likes to think ahead...
>
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.
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Rename Postgres 19 to Postgres 26 (year-based)?
2026-05-21 14:20 Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
2026-05-21 17:44 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Kirk Wolak <[email protected]>
2026-05-21 18:45 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Isaac Morland <[email protected]>
@ 2026-05-22 15:54 ` Tom Lane <[email protected]>
2026-05-24 14:22 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Tom Lane @ 2026-05-22 15:54 UTC (permalink / raw)
To: Isaac Morland <[email protected]>; +Cc: Kirk Wolak <[email protected]>; Nikolay Samokhvalov <[email protected]>; pgsql-hackers <[email protected]>
Isaac Morland <[email protected]> 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?
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Rename Postgres 19 to Postgres 26 (year-based)?
2026-05-21 14:20 Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
2026-05-21 17:44 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Kirk Wolak <[email protected]>
2026-05-21 18:45 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Isaac Morland <[email protected]>
2026-05-22 15:54 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Tom Lane <[email protected]>
@ 2026-05-24 14:22 ` Peter Eisentraut <[email protected]>
2026-05-24 17:03 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Tom Lane <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Peter Eisentraut @ 2026-05-24 14:22 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Isaac Morland <[email protected]>; +Cc: Kirk Wolak <[email protected]>; Nikolay Samokhvalov <[email protected]>; pgsql-hackers <[email protected]>
On 22.05.26 08:54, Tom Lane wrote:
> Isaac Morland <[email protected]> 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.
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Rename Postgres 19 to Postgres 26 (year-based)?
2026-05-21 14:20 Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
2026-05-21 17:44 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Kirk Wolak <[email protected]>
2026-05-21 18:45 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Isaac Morland <[email protected]>
2026-05-22 15:54 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Tom Lane <[email protected]>
2026-05-24 14:22 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Peter Eisentraut <[email protected]>
@ 2026-05-24 17:03 ` Tom Lane <[email protected]>
2026-05-24 17:31 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Philip Alger <[email protected]>
2026-05-25 22:21 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
0 siblings, 2 replies; 10+ messages in thread
From: Tom Lane @ 2026-05-24 17:03 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Isaac Morland <[email protected]>; Kirk Wolak <[email protected]>; Nikolay Samokhvalov <[email protected]>; pgsql-hackers <[email protected]>
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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Rename Postgres 19 to Postgres 26 (year-based)?
2026-05-21 14:20 Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
2026-05-21 17:44 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Kirk Wolak <[email protected]>
2026-05-21 18:45 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Isaac Morland <[email protected]>
2026-05-22 15:54 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Tom Lane <[email protected]>
2026-05-24 14:22 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Peter Eisentraut <[email protected]>
2026-05-24 17:03 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Tom Lane <[email protected]>
@ 2026-05-24 17:31 ` Philip Alger <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Philip Alger @ 2026-05-24 17:31 UTC (permalink / raw)
To: pgsql-hackers <[email protected]>
> > 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?
>
> 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.
>
Not only these points, but if a release occurs in December, the version
will seem outdated once the new year arrives in ~31 days. Users or
enterprises will feel compelled, or pressured, to upgrade because the name
will appear ancient to their clients if they are using v2025, for example.
-1 on using the year.
--
Best,
Phil Alger
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Rename Postgres 19 to Postgres 26 (year-based)?
2026-05-21 14:20 Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
2026-05-21 17:44 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Kirk Wolak <[email protected]>
2026-05-21 18:45 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Isaac Morland <[email protected]>
2026-05-22 15:54 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Tom Lane <[email protected]>
2026-05-24 14:22 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Peter Eisentraut <[email protected]>
2026-05-24 17:03 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Tom Lane <[email protected]>
@ 2026-05-25 22:21 ` Nikolay Samokhvalov <[email protected]>
2026-05-25 23:28 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? jian he <[email protected]>
1 sibling, 1 reply; 10+ messages in thread
From: Nikolay Samokhvalov @ 2026-05-25 22:21 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Peter Eisentraut <[email protected]>; Isaac Morland <[email protected]>; Kirk Wolak <[email protected]>; pgsql-hackers <[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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Rename Postgres 19 to Postgres 26 (year-based)?
2026-05-21 14:20 Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
2026-05-21 17:44 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Kirk Wolak <[email protected]>
2026-05-21 18:45 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Isaac Morland <[email protected]>
2026-05-22 15:54 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Tom Lane <[email protected]>
2026-05-24 14:22 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Peter Eisentraut <[email protected]>
2026-05-24 17:03 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Tom Lane <[email protected]>
2026-05-25 22:21 ` Re: Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
@ 2026-05-25 23:28 ` jian he <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: jian he @ 2026-05-25 23:28 UTC (permalink / raw)
To: Nikolay Samokhvalov <[email protected]>; +Cc: Tom Lane <[email protected]>; Peter Eisentraut <[email protected]>; Isaac Morland <[email protected]>; Kirk Wolak <[email protected]>; pgsql-hackers <[email protected]>
On Tue, May 26, 2026 at 6:22 AM Nikolay Samokhvalov <[email protected]> wrote:
>
> 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
>
https://www.postgresql.org/docs/
After "PDF Version", add another column makes sense to me.
> https://www.postgresql.org/docs/release/
> https://www.postgresql.org/docs/current/index.html
For these two links, I'm not entirely sure where the best place to put
that information would be.
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2026-05-25 23:28 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-05-21 14:20 Rename Postgres 19 to Postgres 26 (year-based)? Nikolay Samokhvalov <[email protected]>
2026-05-21 15:18 ` Junwang Zhao <[email protected]>
2026-05-21 17:44 ` Kirk Wolak <[email protected]>
2026-05-21 18:45 ` Isaac Morland <[email protected]>
2026-05-22 15:54 ` Tom Lane <[email protected]>
2026-05-24 14:22 ` Peter Eisentraut <[email protected]>
2026-05-24 17:03 ` Tom Lane <[email protected]>
2026-05-24 17:31 ` Philip Alger <[email protected]>
2026-05-25 22:21 ` Nikolay Samokhvalov <[email protected]>
2026-05-25 23:28 ` jian he <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox