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

From: Junwang Zhao <zhjwpku(at)gmail(dot)com>
To: Nikolay Samokhvalov <nik(at)postgres(dot)ai>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Rename Postgres 19 to Postgres 26 (year-based)?
Date: 2026-05-21 15:18:54
Message-ID: CAEG8a3Las-N6-rEc22Vr=kvHk4YJrUvH70NkC8-e+-OmmqeWjw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 21, 2026 at 10:20 PM Nikolay Samokhvalov <nik(at)postgres(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Imran Zaheer 2026-05-21 16:32:36 effective_wal_level is not decreasing after using REPACK (CONCURRENTLY)
Previous Message Matheus Alcantara 2026-05-21 15:12:56 Re: Avoid leaking system path from pg_available_extensions