| From: | Philip Alger <paalger0(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Rename Postgres 19 to Postgres 26 (year-based)? |
| Date: | 2026-05-24 17:31:55 |
| Message-ID: | CAPXBC8LibVcuxiLoo_c2DLTmNh3sN0soyyGgRcdeKX8Zdpd5qw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> > 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mats Kindahl | 2026-05-24 18:30:17 | Re: pg_rewind does not rewind diverging timelines |
| Previous Message | Tom Lane | 2026-05-24 17:03:59 | Re: Rename Postgres 19 to Postgres 26 (year-based)? |