MIME-Version: 1.0
References: 
 <CAM527d9HNDGS4wZBNK8vhRXtRX09i4UwKjvifUvSPS+P-i-1CQ@mail.gmail.com>
 <CACLU5mSnxYVf1ZkuZ4VuiREXA_42fe22+fR38y2_JJ6+WJQGyw@mail.gmail.com>
 <CAMsGm5fPUwBxgY2RGGzpEp7Sjv7VMU28vcjN+RmuWQpTWM2uRA@mail.gmail.com>
 <26422.1779465244@sss.pgh.pa.us>
 <0e41a002-ec9d-4acd-bb2c-3104c12607e3@eisentraut.org>
 <2293454.1779642239@sss.pgh.pa.us>
In-Reply-To: <2293454.1779642239@sss.pgh.pa.us>
From: Philip Alger <paalger0@gmail.com>
Date: Sun, 24 May 2026 12:31:55 -0500
Message-ID: 
 <CAPXBC8LibVcuxiLoo_c2DLTmNh3sN0soyyGgRcdeKX8Zdpd5qw@mail.gmail.com>
Subject: Re: Rename Postgres 19 to Postgres 26 (year-based)?
To: pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000001346bb065293a492"
Archived-At: 
 <https://www.postgresql.org/message-id/CAPXBC8LibVcuxiLoo_c2DLTmNh3sN0soyyGgRcdeKX8Zdpd5qw%40mail.gmail.com>
Precedence: bulk

--0000000000001346bb065293a492
Content-Type: text/plain; charset="UTF-8"

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

--0000000000001346bb065293a492
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><div><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; On 22.05.26 08:54, Tom Lane wrote:<br>
&gt;&gt; I don&#39;t like either version of this proposal, because I fear i=
t<br>
&gt;&gt; puts way too much faith in our ability to adhere to a fixed releas=
e<br>
&gt;&gt; calendar.=C2=A0 What happens if &quot;v2027&quot; slips into 2028?=
=C2=A0 Are we then<br>
&gt;&gt; unable to resume the normal schedule for the following release?<br=
></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
A different angle came up in the AI-focused unconference session at<br>
PGConf.dev: somebody speculated that use of AI might accelerate our<br>
development cycle to the point where it&#39;d be sensible to have two<br>
major releases per year.=C2=A0<br></blockquote><div><br></div><div>Not only=
 these points, but if a release occurs in December, the version will seem o=
utdated once the new year arrives in ~31 days. Users or enterprises will fe=
el 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 yea=
r.</div><div><br></div></div></div><div><br></div><span class=3D"gmail_sign=
ature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature" data=
-smartmail=3D"gmail_signature"><div dir=3D"ltr">Best,<div>Phil Alger</div><=
div><font color=3D"#000000" face=3D"arial, sans-serif"><span style=3D"backg=
round-color:rgba(232,232,232,0.04)">EDB: </span><a href=3D"https://www.ente=
rprisedb.com/" rel=3D"noopener noreferrer" style=3D"background-color:rgba(2=
32,232,232,0.04)" target=3D"_blank">https://www.enterprisedb.com</a></font>=
</div></div></div></div>

--0000000000001346bb065293a492--