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: Nikolay Samokhvalov <nik@postgres.ai>
Date: Mon, 25 May 2026 15:21:45 -0700
Message-ID: 
 <CAM527d_bY2Rcadq9sUckuVxAysU=kA2GeyG1XfRan1J2VYvDKw@mail.gmail.com>
Subject: Re: Rename Postgres 19 to Postgres 26 (year-based)?
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter@eisentraut.org>,
 Isaac Morland <isaac.morland@gmail.com>,
	Kirk Wolak <wolakk@gmail.com>,
 pgsql-hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000783f020652abce6f"
Archived-At: 
 <https://www.postgresql.org/message-id/CAM527d_bY2Rcadq9sUckuVxAysU%3DkA2GeyG1XfRan1J2VYvDKw%40mail.gmail.com>
Precedence: bulk

--000000000000783f020652abce6f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, May 24, 2026 at 10:04=E2=80=AFAM Tom Lane <tgl@sss.pgh.pa.us> wrote=
:

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


Understood. Thank you both for the direct responses.

The slip risk, the N+1 marketing-renumbering precedent, and the possibility
that cadence may change (biannual or otherwise) -- all make sense.

Year-tied version numbers don't fit. Let me propose something smaller that
still addresses the underlying user problem =E2=80=94 knowing at a glance h=
ow old a
release is and when it goes EOL.

I have another, much lighter proposal. In fact, two paths:

1) Docs. Add something like "Major version NN released YYYY, EOL Mon YYYY"
explicitly on pages like:

https://www.postgresql.org/docs/
https://www.postgresql.org/docs/release/
https://www.postgresql.org/docs/current/index.html

Today, anyone reasoning about a Postgres version's age has to navigate to
https://www.postgresql.org/support/versioning/ and read the table.
Operators, support engineers, and vendors documenting compatibility do this
constantly. Putting the two dates inline on the docs landing pages removes
that lookup.

2) Annual-release label, alongside the version number. In release
announcements, news posts, and the press kit:

PostgreSQL 19 (2026)

and where prose flows naturally: "PostgreSQL 19, the 2026 annual major
release."

This doesn't tie the version to the year; the integer is still
authoritative. If slippage occurs, it only adjusts the label, and if the
cadence shifts to biannual, it naturally extends to "(2026.1)" / "(2026.2)"
without touching the version number. It's a parallel naming, not a
replacement.

Nik

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

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, M=
ay 24, 2026 at 10:04=E2=80=AFAM Tom Lane &lt;<a href=3D"mailto:tgl@sss.pgh.=
pa.us" target=3D"_blank">tgl@sss.pgh.pa.us</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Peter Eisentraut &lt;<a href=3D"m=
ailto:peter@eisentraut.org" target=3D"_blank">peter@eisentraut.org</a>&gt; =
writes:<br>
&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=
>
<br>
&gt; Furthermore, some things that release toward the end of year N are <br=
>
&gt; released as version N+1, for marketing reasons.=C2=A0 So this approach=
 <br>
&gt; wouldn&#39;t even really reduce ambiguity or the need for more arguing=
.<br>
<br>
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 I&#39;m not saying I believe that, mind you.=
<br>
But it reinforces the point that tying our release numbers to years<br>
would put undesirable constraints on our release calendar.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 regards, tom lane<br></blockquote><div><br></div><div><br></div>=
Understood. Thank you both for the direct responses.<br><br>The slip risk, =
the N+1 marketing-renumbering precedent, and the possibility that cadence m=
ay change (biannual or otherwise) -- all make=C2=A0sense.</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Year-tied version num=
bers don&#39;t fit. Let me propose something smaller that still addresses t=
he underlying user problem =E2=80=94 knowing at a glance how old a release =
is and when it goes EOL.</div><div class=3D"gmail_quote"><br></div><div cla=
ss=3D"gmail_quote">I have another, much lighter proposal.=C2=A0In fact, two=
 paths:<br><br>1) Docs. Add something like &quot;Major version NN released =
YYYY, EOL Mon YYYY&quot; explicitly on pages like:<br><br><a href=3D"https:=
//www.postgresql.org/docs/">https://www.postgresql.org/docs/</a><br><a href=
=3D"https://www.postgresql.org/docs/release/">https://www.postgresql.org/do=
cs/release/</a><br><a href=3D"https://www.postgresql.org/docs/current/index=
.html">https://www.postgresql.org/docs/current/index.html</a><br><br>Today,=
 anyone reasoning about a Postgres version&#39;s age has to navigate to <a =
href=3D"https://www.postgresql.org/support/versioning/">https://www.postgre=
sql.org/support/versioning/</a> and read the table. Operators, support engi=
neers, and vendors documenting compatibility do this constantly. Putting th=
e two dates inline on the docs landing pages removes that lookup.<br><br>2)=
 Annual-release label, alongside the version number. In release announcemen=
ts, news posts, and the press kit:<br><br>PostgreSQL 19 (2026)<br><br>and w=
here prose flows naturally: &quot;PostgreSQL 19, the 2026 annual major rele=
ase.&quot;<br><br>This doesn&#39;t tie the version to the year; the integer=
 is still authoritative. If slippage occurs, it only adjusts the label, and=
 if the cadence shifts to biannual, it naturally extends to &quot;(2026.1)&=
quot; / &quot;(2026.2)&quot; without touching the version number. It&#39;s =
a parallel naming, not a replacement.</div><div class=3D"gmail_quote"><br><=
/div><div class=3D"gmail_quote"><div>Nik=C2=A0</div></div></div>
</div>

--000000000000783f020652abce6f--