| 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
| 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 |