Rename Postgres 19 to Postgres 26 (year-based)?
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
On Thu, May 21, 2026 at 10:20 PM Nikolay Samokhvalov <nik@postgres.ai> 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
On Thu, May 21, 2026 at 10:20 AM Nikolay Samokhvalov <nik@postgres.ai>
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!
On Thu, 21 May 2026 at 13:44, Kirk Wolak <wolakk@gmail.com> 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.
Isaac Morland <isaac.morland@gmail.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?
regards, tom lane
On 22.05.26 08:54, Tom Lane wrote:
Isaac Morland <isaac.morland@gmail.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.
Peter Eisentraut <peter@eisentraut.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
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