Re: Just for fun: Postgres 20?

[Avinash Kumar]

On Tue, Jun 2, 2020 at 2:45 PM Robert Haas  wrote:

> On Mon, Jun 1, 2020 at 3:20 PM Tom Lane  wrote:
> > Robert Haas  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: MMDDN. 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.
>
Since there is a proposal to have a 64-bit transaction ID, we could rather
have a 64-bit random number which could solve all of these problems. :P
And then if I ask my customer what Postgres version is he/she using, it
could be a postgres fun ride.

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

-- 
Regards,
Avinash Vallarapu

Re: Just for fun: Postgres 20?

[Robert Haas]

On Mon, Jun 1, 2020 at 3:20 PM Tom Lane  wrote:
> Robert Haas  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: MMDDN. 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

Re: Just for fun: Postgres 20?

[Tom Lane]

Robert Haas  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: MMDDN. 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

Re: Just for fun: Postgres 20?

[Robert Haas]

On Wed, Feb 12, 2020 at 11:25 AM Juan José Santamaría Flecha
 wrote:
> On Wed, Feb 12, 2020 at 3:47 PM 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.
>
> We could you use  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?

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: MMDDN. 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

Re: Just for fun: Postgres 20?

[Jiří Fejfar]

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

Re: Just for fun: Postgres 20?

[Bruce Momjian]

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

Re: Just for fun: Postgres 20?

[Wolfgang Wilhelm]

 
Please don't take personal but when you open a discussion like that on number 
13 then you are doing something very christian centric and forget the rest of 
the world. As there are more cultural spheres than the christian one on this 
planet can you please elaborate the next number which is acceptable 
(PostgreSQL) world wide? 
May I assist you a little bit? The number 4 in japanese and chinese are spoken 
the same way as the word for death. 14 is spoken as ten-four. That'd a reason 
to skip PostgreSQL ten-death a.k.a. 14, too, isn't it? You don't want a PG 
death version, do you? By the way: In Japan or in jewish tradition 13 is a 
lucky number (see Freitag, der 13. – Wikipedia, sorry, german only). Why do you 
want to skip a lucky number? Do you prefer PostgreSQL ju-san because that's a 
lucky number instead of PostgreSQL 13 because that's a unlucky one?






   Am Montag, 25. Mai 2020, 11:04:53 MESZ hat Jiří Fejfar 
 Folgendes geschrieben:  
 
 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ří.



  

Re: Just for fun: Postgres 20?

[Jiří Fejfar]

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ří.

Re: Just for fun: Postgres 20?

[Bruce Momjian]

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

Re: Just for fun: Postgres 20?

[Andrew Dunstan]

On Fri, Feb 14, 2020 at 7:19 PM Tom Lane  wrote:
>
> Andrew Dunstan  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 Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Just for fun: Postgres 20?

[Peter Geoghegan]

On Thu, Feb 13, 2020 at 1:34 PM Andrew Dunstan
 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

Re: Just for fun: Postgres 20?

[Peter Geoghegan]

On Fri, Feb 14, 2020 at 4:19 PM Tom Lane  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

Re: Just for fun: Postgres 20?

[Tom Lane]

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

Re: Just for fun: Postgres 20?

[Andrew Dunstan]

On Thu, Feb 13, 2020 at 2:14 PM Michael Paquier  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 Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Just for fun: Postgres 20?

[Michael Paquier]

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


signature.asc
Description: PGP signature

Re: Just for fun: Postgres 20?

[Michael Banck]

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.ba...@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

Re: Just for fun: Postgres 20?

[Ray O'Donnell]

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  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  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
r...@rodonnell.ie

Re: Just for fun: Postgres 20?

[David Fetter]

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  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  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  http://fetter.org/
Phone: +1 415 235 3778

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

Re: Just for fun: Postgres 20?

[Isaac Morland]

On Wed, 12 Feb 2020 at 14:58, Laurenz Albe  wrote:

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

Agreed. That being said, everybody knows you can't avoid the curse of 13 by
re-numbering it - you simply have to avoid the version/floor/day/whatever
after 12.

Re: Just for fun: Postgres 20?

[Laurenz Albe]

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

Re: Just for fun: Postgres 20?

[Christopher Browne]

On Wed, 12 Feb 2020 at 08:28, 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.
>

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

Perhaps we could avert it by doing an "April Fool's Postgres 13" release?
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

Re: Just for fun: Postgres 20?

[Juan José Santamaría Flecha]

On Wed, Feb 12, 2020 at 3:47 PM 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.
>
>
We could you use  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?

Regards,

Juan José Santamaría Flecha

Re: Just for fun: Postgres 20?

[Alvaro Herrera]

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 Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Just for fun: Postgres 20?

[Tom Lane]

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

Re: Just for fun: Postgres 20?

[Andreas Karlsson]

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

Re: Just for fun: Postgres 20?

[Alvaro Herrera]

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 Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Just for fun: Postgres 20?

[marcelo zen]

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.

On Tue, 11 Feb 2020 at 14:03, Andreas Joseph Krogh 
wrote:

> This project already tried that:
> https://www.postgresql.org/docs/12/history.html#HISTORY-POSTGRES95
> Didn't last long...
>
> --
> Andreas Joseph Krogh
>

Sv: Just for fun: Postgres 20?

[Andreas Joseph Krogh]

This project already tried that: 
https://www.postgresql.org/docs/12/history.html#HISTORY-POSTGRES95 
 
Didn't last long... 


--
 Andreas Joseph Krogh 

Re: Just for fun: Postgres 20?

[Joshua Drake]

>
>
> From: Jose Luis Tallon 
>
> >  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.
>
>
There are multiple pros and cons to this idea. There is an argument since
we are on annual releases that 20 makes sense, and (14) would be 21 etc...
However, there is a significant problem with that. Our annual releases are
a relatively new thing and I can definitely see a situation in the future
where we move back to non-annual releases to a more conservative timeline.
Further, the jump of the number is going to be seen as a marketing ploy and
if we are going to be doing marketing ploys, then we should have the new
feature set to back it up upon release.

JD

Re: Just for fun: Postgres 20?

[Wolfgang Wilhelm]

 And nobody is asking about all the "missing" versions like in a big red 
superstitious database.


Am Montag, 10. Februar 2020, 00:45:02 MEZ hat tsunakawa.ta...@fujitsu.com 
 Folgendes geschrieben:  
 
 From: Jose Luis Tallon 
>      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

  

RE: Just for fun: Postgres 20?

[tsunakawa.ta...@fujitsu.com]

From: Jose Luis Tallon 
>      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

Re: Just for fun: Postgres 20?

[Tom Lane]

Jose Luis Tallon  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

Re: Just for fun: Postgres 20?

[Vik Fearing]

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

Just for fun: Postgres 20?

[Jose Luis Tallon]

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.