Thread: Just for fun: Postgres 20?

Hackers,

     Musing some other date-related things I stumbled upon the thought 
that naming the upcoming release PostgreSQL 20 might be preferrable to 
the current/expected "PostgreSQL 13".


Cons:

  * Discontinuity in versions. 12 -> 20.  Now that we have the precedent 
of 9.6 -> 10 (for very good reasons, I think), this is probably a minor 
issue... Mostly the inconvenience of having to add tests for the skipped 
versions, I believe.

     ¿any others that I don't know about?

Pros:

  * Simplified supportability assessment:  PostgreSQL 20, released in 
2020, would be supported until the release of PostgreSQL 25 (late 2025 
if release cadence is kept as today). Simple and straightforward.

  * We avoid users skipping the release altogether due to superstition 
or analogous reasons ---might be a major issue in some cultures---. 
Postgres 13 would be certainly skipped in production in some 
environments that I know about o_0


Nothing really important, I guess. I think of it as a thought experiment 
mostly, but might spark some ultimate useful debate.


Thanks,

     / J.L.

On 09/02/2020 19:28, Jose Luis Tallon wrote:
>  * Simplified supportability assessment:  PostgreSQL 20, released in
> 2020, would be supported until the release of PostgreSQL 25 (late 2025
> if release cadence is kept as today). Simple and straightforward.

How would you handle multiple releases in the same calendar year (such
as 9.5 and 9.6 were)?

>  * We avoid users skipping the release altogether due to superstition or
> analogous reasons ---might be a major issue in some cultures---.
> Postgres 13 would be certainly skipped in production in some
> environments that I know about o_0

That's not our problem.
-- 
Vik Fearing

Jose Luis Tallon <jltallon@adv-solutions.net> writes:
>      Musing some other date-related things I stumbled upon the thought 
> that naming the upcoming release PostgreSQL 20 might be preferrable to 
> the current/expected "PostgreSQL 13".

Sorry, but it's not April 1st yet.

            regards, tom lane

From: Jose Luis Tallon <jltallon@adv-solutions.net>
>      Musing some other date-related things I stumbled upon the thought
> that naming the upcoming release PostgreSQL 20 might be preferrable to
> the current/expected "PostgreSQL 13".

+1
Users can easily know how old/new the release is that they are using.


Regards
Takayuki Tsunakawa

marcelo zen escribió:
> I'd rather have releases being made when the software is ready and not when
> the calendar year mandates it.
> It seems like a terrible idea.

But we do actually release on calendar year.  While it seems not
unreasonable that we might fail to ship in time, that would likely lead
to one month, two months of delay.  Four months?  I don't think anybody
even imagines such a long delay.  It would be seen as utter,
unacceptable failure of our release team.

Others have commented in this thread that the idea seems ridiculous, and
I concur.  But the reason is not what you say.  The reason, I think, is
that for years we spent months each time debating what to name the next
release; and only recently, in version 10, we decided to change our
numbering scheme so that these pointless discussions are gone for good.
To think that just three years after that we're going to waste months
again discussing the same topic ...?  Surely not.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 2/12/20 12:07 AM, Alvaro Herrera wrote:
> marcelo zen escribió:
>> I'd rather have releases being made when the software is ready and not when
>> the calendar year mandates it.
>> It seems like a terrible idea.
> 
> But we do actually release on calendar year.  While it seems not
> unreasonable that we might fail to ship in time, that would likely lead
> to one month, two months of delay.  Four months?  I don't think anybody
> even imagines such a long delay.  It would be seen as utter,
> unacceptable failure of our release team.

It has actually happened once: PostgreSQL 9.5 was released in 2016-01-07.

> Others have commented in this thread that the idea seems ridiculous, and
> I concur.  But the reason is not what you say.  The reason, I think, is
> that for years we spent months each time debating what to name the next
> release; and only recently, in version 10, we decided to change our
> numbering scheme so that these pointless discussions are gone for good.
> To think that just three years after that we're going to waste months
> again discussing the same topic ...?  Surely not.

Agreed, and personally I do not see enough benefit from moving to 20.X 
or 2020.X for it to be worth re-opening this discussion. The bikeshed is 
already painted.

Andreas

Andreas Karlsson <andreas@proxel.se> writes:
> On 2/12/20 12:07 AM, Alvaro Herrera wrote:
>> But we do actually release on calendar year.  While it seems not
>> unreasonable that we might fail to ship in time, that would likely lead
>> to one month, two months of delay.  Four months?  I don't think anybody
>> even imagines such a long delay.  It would be seen as utter,
>> unacceptable failure of our release team.

> It has actually happened once: PostgreSQL 9.5 was released in 2016-01-07.

Yeah; I don't think it's *that* unlikely for it to happen again.  But
my own principal concern about this mirrors what somebody else already
pointed out: the one-major-release-per-year schedule is not engraved on
any stone tablets.  So I don't want to go to a release numbering system
that depends on us doing it that way for the rest of time.

            regards, tom lane

Andreas Karlsson escribió:
> On 2/12/20 12:07 AM, Alvaro Herrera wrote:
> > marcelo zen escribió:
> > > I'd rather have releases being made when the software is ready and not when
> > > the calendar year mandates it.
> > > It seems like a terrible idea.
> > 
> > But we do actually release on calendar year.  While it seems not
> > unreasonable that we might fail to ship in time, that would likely lead
> > to one month, two months of delay.  Four months?  I don't think anybody
> > even imagines such a long delay.  It would be seen as utter,
> > unacceptable failure of our release team.
> 
> It has actually happened once: PostgreSQL 9.5 was released in 2016-01-07.

We didn't have a formal release team back then :-)  It started with 9.6.
Some history: https://wiki.postgresql.org/wiki/RMT  Anyway, I concede
that it's too recent history to say that this will never happen again.

Retroactively we could still have named "Postgres 15" the one released
on January 2016.  It was clearly the development line made during 2015,
it just got a little bit delayed.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Wed, 2020-02-12 at 12:32 -0500, Christopher Browne wrote:
> All said, I think there's some merit to avoiding a PostgreSQL 13 release, because
> there's enough superstition out there about the infamous "number 13."

It would make me sad if the project kotowed to superstition like Oracle did.

Yours,
Laurenz Albe

On Wed, Feb 12, 2020 at 05:25:15PM +0100, Juan José Santamaría Flecha wrote:
> On Wed, Feb 12, 2020 at 3:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> >
> > Yeah; I don't think it's *that* unlikely for it to happen again.  But
> > my own principal concern about this mirrors what somebody else already
> > pointed out: the one-major-release-per-year schedule is not engraved on
> > any stone tablets.  So I don't want to go to a release numbering system
> > that depends on us doing it that way for the rest of time.
> >
> >
> We could you use YYYY as version identifier, so people will not expect
> correlative numbering. SQL Server is being released every couple of years
> and they are using this naming shema. The problem would be releasing twice
> the same year, but how likely would that be?

We've released more than one major version in a year before, so we
have a track record of that actually happening.

Best,
David.
-- 
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

On 12/02/2020 21:10, David Fetter wrote:
> On Wed, Feb 12, 2020 at 05:25:15PM +0100, Juan José Santamaría Flecha wrote:
>> On Wed, Feb 12, 2020 at 3:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>>>
>>> Yeah; I don't think it's *that* unlikely for it to happen again.  But
>>> my own principal concern about this mirrors what somebody else already
>>> pointed out: the one-major-release-per-year schedule is not engraved on
>>> any stone tablets.  So I don't want to go to a release numbering system
>>> that depends on us doing it that way for the rest of time.
>>>
>>>
>> We could you use YYYY as version identifier, so people will not expect
>> correlative numbering. SQL Server is being released every couple of years
>> and they are using this naming shema. The problem would be releasing twice
>> the same year, but how likely would that be?
> 
> We've released more than one major version in a year before, so we
> have a track record of that actually happening.

Besides what everyone else has said, it's not that long since the
numbering scheme was changed for major versions. Changing it again so
soon would, IMHO, look confused at best.

Ray.

-- 
Raymond O'Donnell // Galway // Ireland
ray@rodonnell.ie

Hi,

On Wed, Feb 12, 2020 at 02:52:53PM +0100, Andreas Karlsson wrote:
> On 2/12/20 12:07 AM, Alvaro Herrera wrote:
> > marcelo zen escribió:
> > > I'd rather have releases being made when the software is ready and
> > > not when the calendar year mandates it.  It seems like a terrible
> > > idea.
> > 
> > But we do actually release on calendar year.  While it seems not
> > unreasonable that we might fail to ship in time, that would likely lead
> > to one month, two months of delay.  Four months?  I don't think anybody
> > even imagines such a long delay.  It would be seen as utter,
> > unacceptable failure of our release team.
> 
> It has actually happened once: PostgreSQL 9.5 was released in 2016-01-07.

It was my undestanding that this prompted us to form the release team,
which has since done a great job of making sure that this does not
happen again.

Of course, this does not mean it won't ever happen again. Even then,
shipping PostgreSQL 23 at the beginning of 2024 wouldn't be a total
disaster in my opinion.

The fact that the community might want to re-think the major release
cycle at some point and not be tied to yearly release numbers is the
most convincing argument against it.

That, and the PR-style "sell-out" it might be regarded as.


Michael

-- 
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax:  +49 2166 9901-100
Email: michael.banck@credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

On Wed, Feb 12, 2020 at 09:46:48AM -0500, Tom Lane wrote:
> Yeah; I don't think it's *that* unlikely for it to happen again.  But
> my own principal concern about this mirrors what somebody else already
> pointed out: the one-major-release-per-year schedule is not engraved on
> any stone tablets.  So I don't want to go to a release numbering system
> that depends on us doing it that way for the rest of time.

Yeah, it is good to keep some flexibility here, so my take is that
there is little advantage in changing again the version numbering.
Note that any change like that induces an extra cost for anybody
maintaining builds of Postgres or any upgrade logic where the decision
depends on the version number of the origin build and the target
build.
--
Michael

On Thu, Feb 13, 2020 at 2:14 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Feb 12, 2020 at 09:46:48AM -0500, Tom Lane wrote:
> > Yeah; I don't think it's *that* unlikely for it to happen again.  But
> > my own principal concern about this mirrors what somebody else already
> > pointed out: the one-major-release-per-year schedule is not engraved on
> > any stone tablets.  So I don't want to go to a release numbering system
> > that depends on us doing it that way for the rest of time.
>
> Yeah, it is good to keep some flexibility here, so my take is that
> there is little advantage in changing again the version numbering.
> Note that any change like that induces an extra cost for anybody
> maintaining builds of Postgres or any upgrade logic where the decision
> depends on the version number of the origin build and the target
> build.

+1

I also object because 20 is *my* unlucky number ...

cheers

andrew



-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> I also object because 20 is *my* unlucky number ...

Not sure how serious Andrew is being here, but it does open up an
important point: there are varying opinions on which numbers are unlucky.
The idea that 13 is unlucky is Western, and maybe even only common in
English-speaking countries.  In Asia, numbers containing the digit 4
are considered unlucky [1], and there are probably other rules in other
cultures.  If we establish a precedent that we'll skip release numbers
for non-technical reasons, I'm afraid we'll be right back in the mess
we sought to avoid, whereby nearly every year we had an argument about
what the next release number would be.  So let's not go there.

            regards, tom lane

[1] https://en.wikipedia.org/wiki/Tetraphobia

On Fri, Feb 14, 2020 at 4:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Not sure how serious Andrew is being here, but it does open up an
> important point: there are varying opinions on which numbers are unlucky.
> The idea that 13 is unlucky is Western, and maybe even only common in
> English-speaking countries.

I would wager that this superstition is the main reason why Oracle 12c
was followed by Oracle 18c rather than Oracle 13c. I have no evidence
for this -- I take it on faith.

I feel that I should take the proposal seriously for at least a
moment. The proposal doesn't affect anybody who isn't into numerology.
At the same time, it makes the superstitious people happy (leaving
aside the icosaphobes). Airlines do this with row numbers -- what's
the harm?

There is a real downside to this, though. It is a bad idea, even on
its own terms. If we take the idea seriously, then it has every chance
of being noticed and becoming a big distraction in all sorts of ways.
That might happen anyway, but I think it's less likely this way.

ISTM that the smart thing to do is to ignore it completely. Don't even
try to preempt a silly headline written by some tech journalist
wiseacre.

--
Peter Geoghegan

On Thu, Feb 13, 2020 at 1:34 PM Andrew Dunstan
<andrew.dunstan@2ndquadrant.com> wrote:
> I also object because 20 is *my* unlucky number ...

I don't think we're going to do this, so you don't have to worry on that score.

-- 
Peter Geoghegan

On Fri, Feb 14, 2020 at 7:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> > I also object because 20 is *my* unlucky number ...
>
> Not sure how serious Andrew is being here, but it does open up an
> important point: there are varying opinions on which numbers are unlucky.
> The idea that 13 is unlucky is Western, and maybe even only common in
> English-speaking countries.  In Asia, numbers containing the digit 4
> are considered unlucky [1], and there are probably other rules in other
> cultures.  If we establish a precedent that we'll skip release numbers
> for non-technical reasons, I'm afraid we'll be right back in the mess
> we sought to avoid, whereby nearly every year we had an argument about
> what the next release number would be.  So let's not go there.
>
>


Yes, I was being flippant, in an attempt to make the exact point
you're making cogently but less pithily here.

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Wed, Feb 12, 2020 at 10:38:19PM +0100, Michael Banck wrote:
> Hi,
> 
> On Wed, Feb 12, 2020 at 02:52:53PM +0100, Andreas Karlsson wrote:
> > On 2/12/20 12:07 AM, Alvaro Herrera wrote:
> > > marcelo zen escribió:
> > > > I'd rather have releases being made when the software is ready and
> > > > not when the calendar year mandates it.  It seems like a terrible
> > > > idea.
> > > 
> > > But we do actually release on calendar year.  While it seems not
> > > unreasonable that we might fail to ship in time, that would likely lead
> > > to one month, two months of delay.  Four months?  I don't think anybody
> > > even imagines such a long delay.  It would be seen as utter,
> > > unacceptable failure of our release team.
> > 
> > It has actually happened once: PostgreSQL 9.5 was released in 2016-01-07.
> 
> It was my undestanding that this prompted us to form the release team,
> which has since done a great job of making sure that this does not
> happen again.

FYI, the delay for 9.5 was because the compression method used for JSONB
was discovered to be sub-optimal in August/September.  While a relesae
team might have gotten the release out before January, that isn't
certain.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On 15.02.2020 1:18, Tom Lane wrote:
> The idea that 13 is unlucky is Western, and maybe even only common in 
> English-speaking countries. 

Number 13 (especially Friday 13) is also considered unlucky In Czech 
republic (central Europe, Slavic language).

--

Jiří.

On Mon, May 25, 2020 at 11:05:09AM +0200, Jiří Fejfar wrote:
> On 15.02.2020 1:18, Tom Lane wrote:
> > The idea that 13 is unlucky is Western, and maybe even only common in
> > English-speaking countries.
> 
> Number 13 (especially Friday 13) is also considered unlucky In Czech
> republic (central Europe, Slavic language).

Yeah, it is in a number of places, and we have discussed it, but we have
decided to stay with 13.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

On 26.05.2020 3:55, Bruce Momjian wrote:
> On Mon, May 25, 2020 at 11:05:09AM +0200, Jiří Fejfar wrote:
>> On 15.02.2020 1:18, Tom Lane wrote:
>>> The idea that 13 is unlucky is Western, and maybe even only common in
>>> English-speaking countries.
>> Number 13 (especially Friday 13) is also considered unlucky In Czech
>> republic (central Europe, Slavic language).
> Yeah, it is in a number of places, and we have discussed it, but we have
> decided to stay with 13.

I am definitely not against PG13 nor any other number. I just wanted to 
say, in response to the part of original message from Tom Lane, that 
idea that 13 is unlucky is not only valid in English-speaking countries.

In fact I am trying to test if I am able to discuss something in mailing 
list. I would like to discuss PG extensions related topics later, but I 
feel I do not have enough experience with such communication using email 
(conversation threading, reply to the part of message only, bottom 
posting, formatting, recipients) although I am fascinated by what sort 
of complicated issues is possible to solve this way in community. I 
chose this thread because of its subject "for fun..." to start with 
something simpler than PG extensions. I should have used some emoji 
probably...

--

Jiří

On Wed, Feb 12, 2020 at 11:25 AM Juan José Santamaría Flecha
<juanjo.santamaria@gmail.com> wrote:
> On Wed, Feb 12, 2020 at 3:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Yeah; I don't think it's *that* unlikely for it to happen again.  But
>> my own principal concern about this mirrors what somebody else already
>> pointed out: the one-major-release-per-year schedule is not engraved on
>> any stone tablets.  So I don't want to go to a release numbering system
>> that depends on us doing it that way for the rest of time.
>
> We could you use YYYY as version identifier, so people will not expect correlative numbering. SQL Server is being
releasedevery couple of years and they are using this naming shema. The problem would be releasing twice the same year,
buthow likely would that be? 

As has already been pointed out, it could definitely happen, but we
could solve that by just using a longer version number, say, including
the month and, in case we ever do multiple major releases in the same
month, also the day. In fact, we might as well take it one step
further and use the same format for the release number that we use for
CATALOG_VERSION_NO: YYYYMMDDN. So this fall, piggybacking on the
success of PostgreSQL 10, 11, and 12, we could look then release
PostgreSQL 202009241 or so.  As catversion.h wisely points out,
there's room to hope that we'll never commit 10 independent sets of
catalog changes on the same day, and I think we can also hope we'll
never do more than ten major releases on the same day. Admittedly,
skipping the version number by 200 million or so might seem like an
overreaction to the purported unluckiness of the number 13, but just
think how many OTHER unlucky numbers we'd also skip in the progress.

/me runs away and hides.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Robert Haas <robertmhaas@gmail.com> writes:
> As has already been pointed out, it could definitely happen, but we
> could solve that by just using a longer version number, say, including
> the month and, in case we ever do multiple major releases in the same
> month, also the day. In fact, we might as well take it one step
> further and use the same format for the release number that we use for
> CATALOG_VERSION_NO: YYYYMMDDN. So this fall, piggybacking on the
> success of PostgreSQL 10, 11, and 12, we could look then release
> PostgreSQL 202009241 or so.

But then where do you put the minor number for maintenance releases?

            regards, tom lane

On Mon, Jun 1, 2020 at 3:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > As has already been pointed out, it could definitely happen, but we
> > could solve that by just using a longer version number, say, including
> > the month and, in case we ever do multiple major releases in the same
> > month, also the day. In fact, we might as well take it one step
> > further and use the same format for the release number that we use for
> > CATALOG_VERSION_NO: YYYYMMDDN. So this fall, piggybacking on the
> > success of PostgreSQL 10, 11, and 12, we could look then release
> > PostgreSQL 202009241 or so.
>
> But then where do you put the minor number for maintenance releases?

Oh, well that's easy. The first maintenance release would just be 202009241.1.

Unless, of course, we want to simplify things by using the same format
for both parts of the version number. Then, supposing the first
maintenance release follows the major release by a month or so, it
would be PostgreSQL 202009241.202010291 or something of this sort.

It's hard to agree on anything around here but I suspect we can come
to near-unanimous agreement on the topic of how much merit this
proposal has.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company