Thread: 10.0

Hi,

There is a long-running thread on pgsql-hackers on whether 9.6 should
instead be called 10.0.  Initially, opinions were mixed, but consensus
seems now to have emerged that 10.0 is a good choice, with the major
hesitation being that we've already released 9.6beta1, and therefore
we might not want to change at this point.  That doesn't seem like an
insuperable barrier to me, but I think it's now time for the
discussion on this topic to move here, because:

1. Some people who have strong opinions may not have followed the
discussion on pgsql-advocacy, and

2. If we're going to rebrand this as 10.0, the work will have to get done here.

The major arguments advanced in favor of 10.0 are:

- There are a lot of exciting features in this release.

- Even if you aren't super-excited by the features in this release,
PostgreSQL 9.6/10.0 is a world away from 10.0, and therefore it makes
sense to bump the version based on the amount of accumulated change
between then and now.

Thoughts?  Is it crazy to go from 9.6beta1 to 10.0beta2?  What would
actually be involved in making the change?

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

On Fri, May 13, 2016 at 11:05:23AM -0400, Robert Haas wrote:
> Hi,
> 
> There is a long-running thread on pgsql-hackers on whether 9.6 should
> instead be called 10.0.  Initially, opinions were mixed, but consensus
> seems now to have emerged that 10.0 is a good choice, with the major
> hesitation being that we've already released 9.6beta1, and therefore
> we might not want to change at this point.  That doesn't seem like an
> insuperable barrier to me, but I think it's now time for the
> discussion on this topic to move here, because:
> 
> 1. Some people who have strong opinions may not have followed the
> discussion on pgsql-advocacy, and
> 
> 2. If we're going to rebrand this as 10.0, the work will have to get done here.
> 
> The major arguments advanced in favor of 10.0 are:
> 
> - There are a lot of exciting features in this release.
> 
> - Even if you aren't super-excited by the features in this release,
> PostgreSQL 9.6/10.0 is a world away from 10.0, and therefore it makes

I think you meant "a world away from 9.0".

Actually, I don't see the distance from 9.0 as a valid argument as 9.5
was probably also a world away from 9.0.

I prefer calling 9.7 as 10.0 because there will be near-zero-downtime
major upgrades with pg_logical (?), and parallelism will cover more
cases.  Built-in logical replication in 9.7 would be big too, and
another reason to do 9.7 as 10.0.

On the other hand, the _start_ of parallelism in 9.6 could be enough of
a reason to call it 10.0, with the idea that the 10-series is
increasingly parallel-aware.  You could argue that parallelism is a much
bigger deal than near-zero-downtime upgrades.

I think the fundamental issue is whether we want to lead the 10.0 branch
with parallelism, or wait for an administrative change like
near-zero-downtime major upgrades and built-in logical replication.

> sense to bump the version based on the amount of accumulated change
> between then and now.
> 
> Thoughts?  Is it crazy to go from 9.6beta1 to 10.0beta2?  What would
> actually be involved in making the change?

Someone mentioned how Postgres 8.5 became 9.0, but then someone else
said the change was made during alpha releases, not beta.  Can someone
dig up the details?

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

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

On 13 May 2016 at 16:05, Robert Haas <robertmhaas@gmail.com> wrote:
>
> Hi,
>
> There is a long-running thread on pgsql-hackers on whether 9.6 should
> instead be called 10.0.  Initially, opinions were mixed, but consensus
> seems now to have emerged that 10.0 is a good choice, with the major
> hesitation being that we've already released 9.6beta1, and therefore
> we might not want to change at this point.  That doesn't seem like an
> insuperable barrier to me, but I think it's now time for the
> discussion on this topic to move here, because:
>
> 1. Some people who have strong opinions may not have followed the
> discussion on pgsql-advocacy, and
>
> 2. If we're going to rebrand this as 10.0, the work will have to get done here.
>
> The major arguments advanced in favor of 10.0 are:
>
> - There are a lot of exciting features in this release.

True dat.

> - Even if you aren't super-excited by the features in this release,
> PostgreSQL 9.6/10.0 is a world away from 10.0, and therefore it makes
> sense to bump the version based on the amount of accumulated change
> between then and now.

Well, a .6 would be the first:

6.5
7.4
8.4

So a .6 would be the very first.  I think the argument of "accumulated
change" is persuasive.

> Thoughts?  Is it crazy to go from 9.6beta1 to 10.0beta2?  What would
> actually be involved in making the change?

Well, one potential issues is that there may be projects which have
already coded in 9.6 checks for feature support.  I don't know if
there would be any problems from the repo side of things for
beta-testers.

Thom

On 13 May 2016 at 16:19, Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, May 13, 2016 at 11:05:23AM -0400, Robert Haas wrote:
>> Hi,
>>
>> There is a long-running thread on pgsql-hackers on whether 9.6 should
>> instead be called 10.0.  Initially, opinions were mixed, but consensus
>> seems now to have emerged that 10.0 is a good choice, with the major
>> hesitation being that we've already released 9.6beta1, and therefore
>> we might not want to change at this point.  That doesn't seem like an
>> insuperable barrier to me, but I think it's now time for the
>> discussion on this topic to move here, because:
>>
>> 1. Some people who have strong opinions may not have followed the
>> discussion on pgsql-advocacy, and
>>
>> 2. If we're going to rebrand this as 10.0, the work will have to get done here.
>>
>> The major arguments advanced in favor of 10.0 are:
>>
>> - There are a lot of exciting features in this release.
>>
>> - Even if you aren't super-excited by the features in this release,
>> PostgreSQL 9.6/10.0 is a world away from 10.0, and therefore it makes
>
> I think you meant "a world away from 9.0".
>
> Actually, I don't see the distance from 9.0 as a valid argument as 9.5
> was probably also a world away from 9.0.
>
> I prefer calling 9.7 as 10.0 because there will be near-zero-downtime
> major upgrades with pg_logical (?), and parallelism will cover more
> cases.  Built-in logical replication in 9.7 would be big too, and
> another reason to do 9.7 as 10.0.
>
> On the other hand, the _start_ of parallelism in 9.6 could be enough of
> a reason to call it 10.0, with the idea that the 10-series is
> increasingly parallel-aware.  You could argue that parallelism is a much
> bigger deal than near-zero-downtime upgrades.
>
> I think the fundamental issue is whether we want to lead the 10.0 branch
> with parallelism, or wait for an administrative change like
> near-zero-downtime major upgrades and built-in logical replication.
>
>> sense to bump the version based on the amount of accumulated change
>> between then and now.
>>
>> Thoughts?  Is it crazy to go from 9.6beta1 to 10.0beta2?  What would
>> actually be involved in making the change?
>
> Someone mentioned how Postgres 8.5 became 9.0, but then someone else
> said the change was made during alpha releases, not beta.  Can someone
> dig up the details?

We had 8.5 alpha 3, then 9.0 alpha 4:

REL8_5_ALPHA1
REL8_5_ALPHA2
REL8_5_ALPHA3
REL9_0_ALPHA4
REL9_0_ALPHA5
REL9_0_BETA1
REL9_0_BETA2
REL9_0_BETA3
REL9_0_BETA4
REL9_0_RC1

Thom

On Fri, May 13, 2016 at 4:23 PM, Thom Brown <thom@linux.com> wrote:
>
> Well, one potential issues is that there may be projects which have
> already coded in 9.6 checks for feature support.

I suspect that won't be an issue (I never heard of it being for 7.5,
which was released as 8.0 - but is smattered all over pgAdmin 3 for
example) - largely because in such apps we're almost always checking
for a version greater than or less than x.y.

I imagine the bigger issue will be apps that have been written
assuming the first part of the version number is only a single digit.

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 13 May 2016 at 16:29, Dave Page <dpage@pgadmin.org> wrote:
> On Fri, May 13, 2016 at 4:23 PM, Thom Brown <thom@linux.com> wrote:
>>
>> Well, one potential issues is that there may be projects which have
>> already coded in 9.6 checks for feature support.
>
> I suspect that won't be an issue (I never heard of it being for 7.5,
> which was released as 8.0 - but is smattered all over pgAdmin 3 for
> example) - largely because in such apps we're almost always checking
> for a version greater than or less than x.y.
>
> I imagine the bigger issue will be apps that have been written
> assuming the first part of the version number is only a single digit.

Is that likely?  That would be remarkably myopic, but I guess possible.

Thom

Robert Haas <robertmhaas@gmail.com> writes:
> There is a long-running thread on pgsql-hackers on whether 9.6 should
> instead be called 10.0.

First I've seen it mentioned here.

I think you are just about exactly one week too late to bring this up.
Once we've shipped a beta, rebranding is way too confusing.
        regards, tom lane

On 2016-05-13 10:34, Thom Brown wrote:
> On 13 May 2016 at 16:29, Dave Page <dpage@pgadmin.org> wrote:
>> On Fri, May 13, 2016 at 4:23 PM, Thom Brown <thom@linux.com> wrote:
>>> 
>>> Well, one potential issues is that there may be projects which have
>>> already coded in 9.6 checks for feature support.
>> 
>> I suspect that won't be an issue (I never heard of it being for 7.5,
>> which was released as 8.0 - but is smattered all over pgAdmin 3 for
>> example) - largely because in such apps we're almost always checking
>> for a version greater than or less than x.y.
>> 
>> I imagine the bigger issue will be apps that have been written
>> assuming the first part of the version number is only a single digit.
> 
> Is that likely?  That would be remarkably myopic, but I guess possible.
> 
> Thom
We (FreeBSD) had lots of that kind of fallout when 9->10.  Autoconf, and 
other tools
thought we were a.out and not ELF.


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 214-642-9640                 E-Mail: ler@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281

Hi,

There is a long-running thread on pgsql-hackers on whether 9.6 should
instead be called 10.0.  Initially, opinions were mixed, but consensus
seems now to have emerged that 10.0 is a good choice, with the major
hesitation being that we've already released 9.6beta1, and therefore
we might not want to change at this point.  That doesn't seem like an
insuperable barrier to me, but I think it's now time for the
discussion on this topic to move here, because:

1. Some people who have strong opinions may not have followed the
discussion on pgsql-advocacy, and

2. If we're going to rebrand this as 10.0, the work will have to get done here.

The major arguments advanced in favor of 10.0 are:

- There are a lot of exciting features in this release.

- Even if you aren't super-excited by the features in this release,
PostgreSQL 9.6/10.0 is a world away from 10.0, and therefore it makes
sense to bump the version based on the amount of accumulated change
between then and now.

Thoughts?  Is it crazy to go from 9.6beta1 to 10.0beta2?  What would
actually be involved in making the change?

* Dave Page (dpage@pgadmin.org) wrote:
> I imagine the bigger issue will be apps that have been written
> assuming the first part of the version number is only a single digit.

Let's just go with 2016 instead then.

At least then users would see how old the version they're running is (I
was just recently dealing with a 8.4 user...).

Thanks!

Stephen

On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote:
> * Dave Page (dpage@pgadmin.org) wrote:
> > I imagine the bigger issue will be apps that have been written
> > assuming the first part of the version number is only a single digit.
> 
> Let's just go with 2016 instead then.
> 
> At least then users would see how old the version they're running is (I
> was just recently dealing with a 8.4 user...).

We tried, that, "Postgres95".  ;-)

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

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

On Fri, May 13, 2016 at 5:08 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote:
>> * Dave Page (dpage@pgadmin.org) wrote:
>> > I imagine the bigger issue will be apps that have been written
>> > assuming the first part of the version number is only a single digit.
>>
>> Let's just go with 2016 instead then.
>>
>> At least then users would see how old the version they're running is (I
>> was just recently dealing with a 8.4 user...).
>
> We tried, that, "Postgres95".  ;-)

Awesome: Postgres16 > Postgres95.

That won't be confusing now will it? :-)

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote:
> * Dave Page (dpage@pgadmin.org) wrote:
> > I imagine the bigger issue will be apps that have been written
> > assuming the first part of the version number is only a single digit.
>
> Let's just go with 2016 instead then.
>
> At least then users would see how old the version they're running is (I
> was just recently dealing with a 8.4 user...).

We tried, that, "Postgres95".  ;-)

On Fri, May 13, 2016 at 5:08 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote:
>> * Dave Page (dpage@pgadmin.org) wrote:
>> > I imagine the bigger issue will be apps that have been written
>> > assuming the first part of the version number is only a single digit.
>>
>> Let's just go with 2016 instead then.
>>
>> At least then users would see how old the version they're running is (I
>> was just recently dealing with a 8.4 user...).
>
> We tried, that, "Postgres95".  ;-)

Awesome: Postgres16 > Postgres95.

That won't be confusing now will it? :-)

On Fri, May 13, 2016 at 04:34:34PM +0100, Thom Brown wrote:
> On 13 May 2016 at 16:29, Dave Page <dpage@pgadmin.org> wrote:
> > On Fri, May 13, 2016 at 4:23 PM, Thom Brown <thom@linux.com> wrote:
> >>
> >> Well, one potential issues is that there may be projects which
> >> have already coded in 9.6 checks for feature support.
> >
> > I suspect that won't be an issue (I never heard of it being for
> > 7.5, which was released as 8.0 - but is smattered all over pgAdmin
> > 3 for example) - largely because in such apps we're almost always
> > checking for a version greater than or less than x.y.
> >
> > I imagine the bigger issue will be apps that have been written
> > assuming the first part of the version number is only a single
> > digit.
> 
> Is that likely?  That would be remarkably myopic, but I guess
> possible.

You might be astonished at the ubiquity of myopia out in the world.

That's not an argument against 10.0, by the way.  Myopia of that type
tends to come with software quality so low that your best bet is never
to start using it, and your second-best is to eliminate it from your
system at high priority.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

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

Stephen Frost <sfrost@snowman.net> writes:
> On Friday, May 13, 2016, Bruce Momjian <bruce@momjian.us> wrote:
>> On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote:
>>> Let's just go with 2016 instead then.

>> We tried, that, "Postgres95".  ;-)

> Even better, we're being retro!  It's in style! ;)

It would sure put a premium on not slipping releases past December.
If you don't rebrand, you look silly; if you do, you've lost the
ability to put out a new major release in the next year.
        regards, tom lane

On Fri, May 13, 2016 at 5:42 PM, Andreas Joseph Krogh <andreas@visena.com> wrote:

På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas <robertmhaas@gmail.com>:

Hi,

There is a long-running thread on pgsql-hackers on whether 9.6 should
instead be called 10.0.  Initially, opinions were mixed, but consensus
seems now to have emerged that 10.0 is a good choice, with the major
hesitation being that we've already released 9.6beta1, and therefore
we might not want to change at this point.  That doesn't seem like an
insuperable barrier to me, but I think it's now time for the
discussion on this topic to move here, because:

1. Some people who have strong opinions may not have followed the
discussion on pgsql-advocacy, and

2. If we're going to rebrand this as 10.0, the work will have to get done here.

The major arguments advanced in favor of 10.0 are:

- There are a lot of exciting features in this release.

- Even if you aren't super-excited by the features in this release,
PostgreSQL 9.6/10.0 is a world away from 10.0, and therefore it makes
sense to bump the version based on the amount of accumulated change
between then and now.

Thoughts?  Is it crazy to go from 9.6beta1 to 10.0beta2?  What would
actually be involved in making the change?

 

From a non-hacker...

 

From a DBA/application-developer perspective  while there are many exiting

features in 9.6 I'd expect more from 10.0, like some of these features:

- Built in "Drop-in replacement" Multi-master replication

- Built-in per-database replication with sequences and DDL-changes

  (future versions of pglogical might solve this)

- Full (and effective) parallelism "everywhere"

- Improved executor (like Robert Haas suggested), more use of LLVM or similar

- All of Postgres Pro's GIN-improvements for really fast FTS (with proper, index-backed, sorting etc.)

- Pluggable storage-engines

 

 

I'm willing to declare that the likelihood you getting all of these in one release is zero. And there will always be "one more feature left".

David Fetter <david@fetter.org> writes:
> On Fri, May 13, 2016 at 04:34:34PM +0100, Thom Brown wrote:
>> On 13 May 2016 at 16:29, Dave Page <dpage@pgadmin.org> wrote:
>>> I imagine the bigger issue will be apps that have been written
>>> assuming the first part of the version number is only a single
>>> digit.

>> Is that likely?  That would be remarkably myopic, but I guess
>> possible.

> You might be astonished at the ubiquity of myopia out in the world.
> That's not an argument against 10.0, by the way.

Yeah, I do not think this is a very relevant argument.  We certainly
will go to 10.0 at some point; if we tried not to, come 2020 we'd be
shipping 9.10.x which would be just as likely to break badly-written
version parsing code.  So such code will have to be fixed eventually,
and whether we break it this year or next year seems like not our
problem.

I think you could, though, make an argument that breaking such code after
beta1 is a bit unfair.  People expect to be able to do compatibility
testing with a new major version starting with beta1.

More generally, rebranding after beta1 sends a very public signal that
we're a bunch of losers who couldn't make up our minds in a timely
fashion.  We should have discussed this last month; now I think we're
stuck with a decision by default.
        regards, tom lane

On Fri, May 13, 2016 at 5:29 PM, Dave Page <dpage@pgadmin.org> wrote:

On Fri, May 13, 2016 at 4:23 PM, Thom Brown <thom@linux.com> wrote:
>
> Well, one potential issues is that there may be projects which have
> already coded in 9.6 checks for feature support.

I suspect that won't be an issue (I never heard of it being for 7.5,
which was released as 8.0 - but is smattered all over pgAdmin 3 for
example) - largely because in such apps we're almost always checking
for a version greater than or less than x.y.

I imagine the bigger issue will be apps that have been written
assuming the first part of the version number is only a single digit.

If they are, they are already broken by design. But more to the point, unless you're arguing for *never* changing to 10.0, that's not really something that should decide when we do it, because they will break.

We have provided multiple ways to check this. For example, we've had PQserverVersion() since forever which returns an integer that you can just compare. We have never claimed that it would be single digit in any of the fields (first, second *or* third). I honestly don't care at all if those applications break.

(We would, however, have a problem to go above 100 in all fields *except* the first one, since the integer uses a two-digit representation for each)

On Fri, May 13, 2016 at 12:30:47PM -0400, Tom Lane wrote:
> 
> I think you could, though, make an argument that breaking such code
> after beta1 is a bit unfair.  People expect to be able to do
> compatibility testing with a new major version starting with beta1.

One could, but I wouldn't find it terribly persuasive.  As Thom
pointed out, we have actually done this before.

> More generally, rebranding after beta1 sends a very public signal
> that we're a bunch of losers who couldn't make up our minds in a
> timely fashion.  We should have discussed this last month; now I
> think we're stuck with a decision by default.

This, on the other hand, is more persuasive to me.  We now have a much
more public face than we did then.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

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

On 13/05/16 17:42, Andreas Joseph Krogh wrote:
> På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas
> <robertmhaas@gmail.com <mailto:robertmhaas@gmail.com>>:
>
>  From a non-hacker...
>  From a DBA/application-developer perspective  while there are many exiting
> features in 9.6 I'd expect more from 10.0, like some of these features:
> - Built in "Drop-in replacement" Multi-master replication
> - Built-in per-database replication with sequences and DDL-changes
>    (future versions of pglogical might solve this)
> - Full (and effective) parallelism "everywhere"
> - Improved executor (like Robert Haas suggested), more use of LLVM or
> similar
> - All of Postgres Pro's GIN-improvements for really fast FTS (with
> proper, index-backed, sorting etc.)
> - Pluggable storage-engines

I think this is actually nice example why we'll have to go the 
accumulation route when deciding to bump to 10, 11, etc. We can't 
possibly get all the major features people want into single release 
given the yearly release cycle.

That being said, I think that once we released beta1 as 9.6 it's too 
late for bumping it.

--   Petr Jelinek                  http://www.2ndQuadrant.com/  PostgreSQL Development, 24x7 Support, Training &
Services

On 5/13/16, Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, May 13, 2016 at 11:05:23AM -0400, Robert Haas wrote:
>> The major arguments advanced in favor of 10.0 are:
>>
>> - There are a lot of exciting features in this release.

If I'm mot mistaken each release introduced exciting features.
In my opinion:
9.5 - kind of UPSERT & RLS;
9.4 - reduced locks for ALTER TABLE, concurrent matview updates and JSONB(!!!);
9.3 - autoupdatable views & LATERAL joins & event trigger;
9.2 - RANGE data types & index-only scans & planner improvements;
9.1 - FDW & extensions & true SERIALIZABLE isolation level & data
modification in CTE.

Each version is a candidate to be 10.0 by the same reasons as people
try to show now.
Since each version has quite big changes and you can't predict how
great changes will be in the next release why don't just increase the
second digit up to 9? As for me version 9.9 is beautiful enough (and
version 9.9.9 is even more beautiful). =)

>> - Even if you aren't super-excited by the features in this release,
>> PostgreSQL 9.6/10.0 is a world away from 10.0, and therefore it makes
>
> I think you meant "a world away from 9.0".
>
> Actually, I don't see the distance from 9.0 as a valid argument as 9.5
> was probably also a world away from 9.0.
>
> I prefer calling 9.7 as 10.0 because there will be near-zero-downtime
> major upgrades with pg_logical (?),

I dream there is time of zero-downtime when admins are instantiate new
version of PostgreSQL, make it slave, wait until it finishes
synchronization (prepare to multimaster), replace both of them as
multimaster online (without downtime), then reconnect clients to the
new instance, then leave new instance as master and shutdown old
version.

If it appears in the release after next one (which is expected be 10.1
or 10.0 or 9.8, i.e. after the next year), whether we update major
number again (11.0) or leave numeration as is (it will be
10.2/10.1/9.9) or it is the real reason to bump 9.8->10.0 (but in this
particular case I'd leave 9.9)?

> and parallelism will cover more cases.
> Built-in logical replication in 9.7 would be big too, and
> another reason to do 9.7 as 10.0.
>
> On the other hand, the _start_ of parallelism in 9.6 could be enough of
> a reason to call it 10.0, with the idea that the 10-series is
> increasingly parallel-aware.  You could argue that parallelism is a much
> bigger deal than near-zero-downtime upgrades.

I think each developer/DBA search for different benefit from each release.
E.g. parallelism is not so important for OLTP developers and
near-zero-downtime is mostly for system administrators/DBA.

> I think the fundamental issue is whether we want to lead the 10.0 branch
> with parallelism, or wait for an administrative change like
> near-zero-downtime major upgrades and built-in logical replication.
>
>   Bruce Momjian  <bruce@momjian.us>        http://momjian.us
>   EnterpriseDB                             http://enterprisedb.com

I'd vote for 9.6 up to 9.9 then 10.0…

--
Best regards,
Vitaly Burovoy

On 05/13/2016 09:30 AM, Tom Lane wrote:

> More generally, rebranding after beta1 sends a very public signal that
> we're a bunch of losers who couldn't make up our minds in a timely
> fashion.  We should have discussed this last month; now I think we're
> stuck with a decision by default.

Although maybe we could use some controversy to get us back in the press ;-)

Anyway, can we come up with a consensus of some minimum changes it will
take to make the next version 10.0?  Here's my thinking:

1. pglogical is accepted into core, with docs/scripts to make it a hot
upgrade option.

2. parallel continues to make progress

My argument is that even if we get nothing else, the above two are
enough to "bump" it to 10.0.  And if we can have argreement on that now,
then we can avoid a month-long argument about version numbers next year.


-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

Josh berkus wrote:
> Anyway, can we come up with a consensus of some minimum changes it will
> take to make the next version 10.0?

I think the next version should be 10.0 no matter what changes we put
in.

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

On 13/05/16 20:31, Alvaro Herrera wrote:
> Josh berkus wrote:
>
>> Anyway, can we come up with a consensus of some minimum changes it will
>> take to make the next version 10.0?
>
> I think the next version should be 10.0 no matter what changes we put
> in.
>

+1

--   Petr Jelinek                  http://www.2ndQuadrant.com/  PostgreSQL Development, 24x7 Support, Training &
Services

On 05/13/2016 11:31 AM, Alvaro Herrera wrote:
> Josh berkus wrote:
>  
>> Anyway, can we come up with a consensus of some minimum changes it will
>> take to make the next version 10.0?
> 
> I think the next version should be 10.0 no matter what changes we put
> in.
> 

Well, if we adopt 2-part version numbers, it will be.  Maybe that's the
easiest thing?  Then we never have to have this discussion again, which
certainly appeals to me ...

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

On Fri, May 13, 2016 at 03:31:37PM -0300, Alvaro Herrera wrote:
> Josh berkus wrote:
>  
> > Anyway, can we come up with a consensus of some minimum changes it will
> > take to make the next version 10.0?
> 
> I think the next version should be 10.0 no matter what changes we put
> in.

+1

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

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

On 05/13/2016 08:31 PM, Alvaro Herrera wrote:
> Josh berkus wrote:
>  
>> Anyway, can we come up with a consensus of some minimum changes it will
>> take to make the next version 10.0?
> 
> I think the next version should be 10.0 no matter what changes we put
> in.

+1

Let's even stamp it 10.0devel from the get-go.
-- 
Vik Fearing                                          +33 6 46 75 15 36
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

Josh berkus wrote:

> Well, if we adopt 2-part version numbers, it will be.  Maybe that's the
> easiest thing?  Then we never have to have this discussion again, which
> certainly appeals to me ...

-1

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

On Fri, May 13, 2016 at 2:45 PM, Vik Fearing <vik@2ndquadrant.fr> wrote:
> On 05/13/2016 08:31 PM, Alvaro Herrera wrote:
>> Josh berkus wrote:
>>
>>> Anyway, can we come up with a consensus of some minimum changes it will
>>> take to make the next version 10.0?
>>
>> I think the next version should be 10.0 no matter what changes we put
>> in.
>
> +1
>
> Let's even stamp it 10.0devel from the get-go.

If making this one 10.0 is out, then I'm for that proposal.

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

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Josh berkus wrote:
>> Anyway, can we come up with a consensus of some minimum changes it will
>> take to make the next version 10.0?

> I think the next version should be 10.0 no matter what changes we put
> in.

Here's my two cents: we called 8.0 that on the basis of the native Windows
port, and 9.0 that on the basis of getting in-core replication support.
Both of those were game-changing features that deserved a "major major"
version number bump.  But as the project matures, it gets harder and
harder to come up with game-changing features in the span of a single
release.  Parallel query is a great example: a fully mature parallel query
feature would, IMO, easily justify a 10.0 moniker.  But what we have today
is more like half or two-thirds of a feature.  If we call this release
10.0 on the strength of that, we could justifiably be accused of
overselling it.  On the other hand, if we wait till next year when
parallelism presumably will be much more fully baked, it'll be a bit
anticlimactic to call it 10.0 then.  This isn't going to get better with
other major features that can be expected to appear in future.  So we can
expect to continue to waste lots of time debating the "what to call it"
question, in pretty much every year except for the one or two immediately
after a "major major" bump.

There's also the problem that the current numbering scheme confuses
people who aren't familiar with the project.  How many times have
you seen people say "I'm using Postgres 8" or "Postgres 9" when asked
what version they're on?

So I think we should solve these problems at a stroke, and save ourselves
lots of breath in the future, by getting rid of the whole "major major"
idea and going over to a two-part version numbering scheme.  To be
specific:

* This year's major release will be 9.6.0, with minor updates 9.6.1,
9.6.2, etc.  It's too late to do otherwise for this release cycle.

* Next year's major release will be 10.0, with minor updates 10.1,
10.2, etc.

* The year after, 11.0.  Etc cetera.

No confusion, no surprises, no debate ever again about what the next
version number is.

This is by no means a new idea, but I think its time has come.
        regards, tom lane

On Fri, May 13, 2016 at 1:46 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, May 13, 2016 at 2:45 PM, Vik Fearing <vik@2ndquadrant.fr> wrote:
>> On 05/13/2016 08:31 PM, Alvaro Herrera wrote:

>>> I think the next version should be 10.0 no matter what changes we put
>>> in.
>>
>> +1
>>
>> Let's even stamp it 10.0devel from the get-go.
>
> If making this one 10.0 is out, then I'm for that proposal.

+1

-- 
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 05/13/2016 08:19 AM, Bruce Momjian wrote:
>> > Thoughts?  Is it crazy to go from 9.6beta1 to 10.0beta2?  What would
>> > actually be involved in making the change?
> Someone mentioned how Postgres 8.5 became 9.0, but then someone else
> said the change was made during alpha releases, not beta.  Can someone
> dig up the details?

/me digs through the announcement archives ...

We changed it to 9.0 for Alpha4.  By Beta1, it was already 9.0.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

Josh berkus <josh@agliodbs.com> writes:
> On 05/13/2016 08:19 AM, Bruce Momjian wrote:
>> Someone mentioned how Postgres 8.5 became 9.0, but then someone else
>> said the change was made during alpha releases, not beta.  Can someone
>> dig up the details?

> /me digs through the announcement archives ...
> We changed it to 9.0 for Alpha4.  By Beta1, it was already 9.0.

Yeah, I'd come to the same conclusion by checking the git history.
7.0 and 8.0 were also rebranded that way in advance of any beta
releases.
        regards, tom lane

On 05/13/2016 11:49 AM, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Josh berkus wrote:
>>> Anyway, can we come up with a consensus of some minimum changes it will
>>> take to make the next version 10.0?
> 
>> I think the next version should be 10.0 no matter what changes we put
>> in.
> 
> Here's my two cents: we called 8.0 that on the basis of the native Windows
> port, and 9.0 that on the basis of getting in-core replication support.
> Both of those were game-changing features that deserved a "major major"
> version number bump.  But as the project matures, it gets harder and
> harder to come up with game-changing features in the span of a single
> release.  Parallel query is a great example: a fully mature parallel query
> feature would, IMO, easily justify a 10.0 moniker.  But what we have today
> is more like half or two-thirds of a feature.  If we call this release
> 10.0 on the strength of that, we could justifiably be accused of
> overselling it.  On the other hand, if we wait till next year when
> parallelism presumably will be much more fully baked, it'll be a bit
> anticlimactic to call it 10.0 then.  This isn't going to get better with
> other major features that can be expected to appear in future.  So we can
> expect to continue to waste lots of time debating the "what to call it"
> question, in pretty much every year except for the one or two immediately
> after a "major major" bump.
> 
> There's also the problem that the current numbering scheme confuses
> people who aren't familiar with the project.  How many times have
> you seen people say "I'm using Postgres 8" or "Postgres 9" when asked
> what version they're on?
> 
> So I think we should solve these problems at a stroke, and save ourselves
> lots of breath in the future, by getting rid of the whole "major major"
> idea and going over to a two-part version numbering scheme.  To be
> specific:
> 
> * This year's major release will be 9.6.0, with minor updates 9.6.1,
> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
> 
> * Next year's major release will be 10.0, with minor updates 10.1,
> 10.2, etc.
> 
> * The year after, 11.0.  Etc cetera.
> 
> No confusion, no surprises, no debate ever again about what the next
> version number is.
> 
> This is by no means a new idea, but I think its time has come.

I'm for it.

Note that we will need to do a *bunch* of education around the change in
version numbering schemes.  And a bunch of people and packagers will
need to change their version comparison scripts (while everyone should
be using the sortable version numbers, not everyone does).

So if we're going to make that change, I suggest doing it *now* to get
the word out.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

Hi,

On 2016-05-13 12:36:00 -0700, Josh berkus wrote:
> On 05/13/2016 11:49 AM, Tom Lane wrote:
> > Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> >> Josh berkus wrote:
> > No confusion, no surprises, no debate ever again about what the next
> > version number is.
> > 
> > This is by no means a new idea, but I think its time has come.
> 
> I'm for it.

I'm not against evolving the numbering scheme. There's a good number of
reasons why the current one is problematic (for me foremost these
discussions ;)).

But because of:

> Note that we will need to do a *bunch* of education around the change in
> version numbering schemes.  And a bunch of people and packagers will
> need to change their version comparison scripts (while everyone should
> be using the sortable version numbers, not everyone does).

I'm in favor of doing something more radical than just stripping one
digit off. We've tried (and only partially failed) to educate users that
$major.$minor updates are the big ones; if we change that to essentially
be $major.$micro, we'll have people not updating and such.

So I'd rather go with 2016.01v0 or something.

Greetings,

Andres Freund

Josh berkus <josh@agliodbs.com> writes:
> On 05/13/2016 11:49 AM, Tom Lane wrote:
>> So I think we should solve these problems at a stroke, and save ourselves
>> lots of breath in the future, by getting rid of the whole "major major"
>> idea and going over to a two-part version numbering scheme.

> I'm for it.

> Note that we will need to do a *bunch* of education around the change in
> version numbering schemes.  And a bunch of people and packagers will
> need to change their version comparison scripts (while everyone should
> be using the sortable version numbers, not everyone does).

Indeed.

> So if we're going to make that change, I suggest doing it *now* to get
> the word out.

Well, actually, part of the reason for proposing that we start it with the
next release cycle is that I think we need lead time to make it happen.
If we try to replace "9.6" with "10" at this stage of the cycle, it's
going to be a mess.  But if we start using that numbering scheme when
we fork the next development branch, there will be time for people to
get used to it.
        regards, tom lane

Andres Freund <andres@anarazel.de> writes:
> I'm in favor of doing something more radical than just stripping one
> digit off. We've tried (and only partially failed) to educate users that
> $major.$minor updates are the big ones; if we change that to essentially
> be $major.$micro, we'll have people not updating and such.

> So I'd rather go with 2016.01v0 or something.

Meh.  We could go with using the year of release as the major version;
that wouldn't be functionally different from what I suggested.  But
I don't want to invent some whole new notation.  That would break
version-comparison scripts for no good reason.  (As an ex-packager for
Red Hat, I know that people who invent their very own version notations
are cordially hated by all distros everywhere.  Let's stick to decimal
numbers with dots between, please.)

Although year-of-release would definitely have the advantage of making
it clear to everybody that Something Changed, I think it would still
be confusing over time.  "Why are you releasing 2017.6 in 2019?"
This is basically the same reason we got rid of the "Postgres95" name,
I believe, though I wasn't around at the time.  There's also the issue
I mentioned upthread that it becomes problematic if a release slips into
January.

My feeling is that going from 9 to 10 will in itself be a pretty good
boundary marker, in a way that wouldn't apply if we were trying to
introduce this scheme starting with 9 or 11.  So this is an ideal
opportunity to get it done.
        regards, tom lane

On Fri, May 13, 2016 at 2:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So I think we should solve these problems at a stroke, and save ourselves
> lots of breath in the future, by getting rid of the whole "major major"
> idea and going over to a two-part version numbering scheme.  To be
> specific:
>
> * This year's major release will be 9.6.0, with minor updates 9.6.1,
> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>
> * Next year's major release will be 10.0, with minor updates 10.1,
> 10.2, etc.
>
> * The year after, 11.0.  Etc cetera.
>
> No confusion, no surprises, no debate ever again about what the next
> version number is.
>
> This is by no means a new idea, but I think its time has come.

Man, I hate version number inflation.  I'm running Firefox 45.0.2, and
I think that's crazy.  It hit 1.0 when were at aversion 7.4!  Granted,
this wouldn't be that bad, but I have always thought that burning
through a first digit a few times a decade is much more sensible than
doing it every year.  We just have to remember to bump the first digit
occasionally.

If we don't want to stick with the current practice of debating when
to bump the same digit, then let's agree that 10.0 will follow 9.6 and
after that we'll bump the first digit after X.4, as we did with 7.X
and 8.X.

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

On 05/13/2016 01:15 PM, Robert Haas wrote:
> On Fri, May 13, 2016 at 2:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So I think we should solve these problems at a stroke, and save ourselves
>> lots of breath in the future, by getting rid of the whole "major major"
>> idea and going over to a two-part version numbering scheme.  To be
>> specific:
>>
>> * This year's major release will be 9.6.0, with minor updates 9.6.1,
>> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>>
>> * Next year's major release will be 10.0, with minor updates 10.1,
>> 10.2, etc.
>>
>> * The year after, 11.0.  Etc cetera.
>>
>> No confusion, no surprises, no debate ever again about what the next
>> version number is.
>>
>> This is by no means a new idea, but I think its time has come.
>
> Man, I hate version number inflation.  I'm running Firefox 45.0.2, and
> I think that's crazy.  It hit 1.0 when were at aversion 7.4!  Granted,
> this wouldn't be that bad, but I have always thought that burning
> through a first digit a few times a decade is much more sensible than
> doing it every year.  We just have to remember to bump the first digit
> occasionally.

Well, FF has this issue because they release a new version every 6
weeks.  Even bumping once per year, we wouldn't hit version 20 until 2027.

> If we don't want to stick with the current practice of debating when
> to bump the same digit, then let's agree that 10.0 will follow 9.6 and
> after that we'll bump the first digit after X.4, as we did with 7.X
> and 8.X.

Why X.4?  Seems arbitrary.

--
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

On 5/13/16, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, May 13, 2016 at 2:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So I think we should solve these problems at a stroke, and save ourselves
>> lots of breath in the future, by getting rid of the whole "major major"
>> idea and going over to a two-part version numbering scheme.  To be
>> specific:
>>
>> * This year's major release will be 9.6.0, with minor updates 9.6.1,
>> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>>
>> * Next year's major release will be 10.0, with minor updates 10.1,
>> 10.2, etc.
>>
>> * The year after, 11.0.  Etc cetera.
>>
>> No confusion, no surprises, no debate ever again about what the next
>> version number is.
>>
>> This is by no means a new idea, but I think its time has come.
>
> Man, I hate version number inflation.

+1

> I'm running Firefox 45.0.2, and I think that's crazy. It hit 1.0 when were
> at aversion 7.4! Granted, this wouldn't be that bad, but

+1
Big numbers in version don't show big (or even equal) changes. How to
compare 7.0…8.0 and 8.0…9.0 and 9.0…9.6(10.0?)?
Is difference between FireFox 10.0…20.0 the same as FireFox 20.0…30.0?

> I have always thought that burning through a first digit a few times a decade
> is much more sensible than doing it every year.
> We just have to remember to bump the first digit occasionally.

+1
Better once a decade. =)

> If we don't want to stick with the current practice of debating when
> to bump the same digit, then let's agree that 10.0 will follow 9.6 and
> after that we'll bump the first digit after X.4, as we did with 7.X
> and 8.X.

Why just don't agree that since each release has good features and we
can't release multiple backward-incompatible features at one release
there is no sense of bumping the first digit earlier than the second
one reaches the value "9"?

Pretend the current version is not 9.5, but 95 (PostgreSQL 95),
current beta not 9.6 but 96 etc, but just divided by 10.

In fact it is similar to Tom's offer but avoided proposed bump to 10.0
and left increasing by 0.1 instead of 1.0:
curnt   Tom's proposed9.5.X  9.5.X9.6.X  9.6.X9.7.X 10.X9.8.X 11.X9.9.X 12.X
10.0.X 13.X
10.1.X 14.X
10.2.X 15.X
...
10.6.X 19.X
10.7.X 20.X
10.8.X 21.X
10.9.X 22.X
11.0.X 23.X
11.1.X 24.X

Etc.

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

--
Best regards,
Vitaly Burovoy

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, May 13, 2016 at 2:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So I think we should solve these problems at a stroke, and save ourselves
>> lots of breath in the future, by getting rid of the whole "major major"
>> idea and going over to a two-part version numbering scheme.

> Man, I hate version number inflation.  I'm running Firefox 45.0.2, and
> I think that's crazy.  It hit 1.0 when were at aversion 7.4!  Granted,
> this wouldn't be that bad, but I have always thought that burning
> through a first digit a few times a decade is much more sensible than
> doing it every year.

Firefox's scheme is weird because they're not really using the back half
of the number at all (not to mention that they then throw in a third part
anyway, some of the time).  If we use up one major-release number per
year, that seems fine to me.

> If we don't want to stick with the current practice of debating when
> to bump the same digit, then let's agree that 10.0 will follow 9.6 and
> after that we'll bump the first digit after X.4, as we did with 7.X
> and 8.X.

It was absolute, utter chance that the 7.x and 8.x series both ended
with .4.  I see no reason to turn that into some kind of standard,
especially when it didn't work like that for 6.x or 9.x.  If we're to go
with a scheme like that, I'd agree with what somebody suggested upthread:
run up to .9 before bumping the first number (ie, 10.0.x would follow
9.9.x).  But this would still leave us with somebody, as sure as the sun
rises in the east, agitating every year to rethink the next release's
number.  That argument is only going to go away if we change the version
number layout so that all major releases look the same; otherwise there
is just too much temptation to argue about it.
        regards, tom lane

On Fri, May 13, 2016 at 1:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> Josh berkus wrote:
>>> Anyway, can we come up with a consensus of some minimum changes it will
>>> take to make the next version 10.0?
>
>> I think the next version should be 10.0 no matter what changes we put
>> in.
>
> Here's my two cents: we called 8.0 that on the basis of the native Windows
> port, and 9.0 that on the basis of getting in-core replication support.
> Both of those were game-changing features that deserved a "major major"
> version number bump.  But as the project matures, it gets harder and
> harder to come up with game-changing features in the span of a single
> release.  Parallel query is a great example: a fully mature parallel query
> feature would, IMO, easily justify a 10.0 moniker.  But what we have today
> is more like half or two-thirds of a feature.  If we call this release
> 10.0 on the strength of that, we could justifiably be accused of
> overselling it.  On the other hand, if we wait till next year when
> parallelism presumably will be much more fully baked, it'll be a bit
> anticlimactic to call it 10.0 then.  This isn't going to get better with
> other major features that can be expected to appear in future.  So we can
> expect to continue to waste lots of time debating the "what to call it"
> question, in pretty much every year except for the one or two immediately
> after a "major major" bump.
>
> There's also the problem that the current numbering scheme confuses
> people who aren't familiar with the project.  How many times have
> you seen people say "I'm using Postgres 8" or "Postgres 9" when asked
> what version they're on?
>
> So I think we should solve these problems at a stroke, and save ourselves
> lots of breath in the future, by getting rid of the whole "major major"
> idea and going over to a two-part version numbering scheme.  To be
> specific:
>
> * This year's major release will be 9.6.0, with minor updates 9.6.1,
> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>
> * Next year's major release will be 10.0, with minor updates 10.1,
> 10.2, etc.
>
> * The year after, 11.0.  Etc cetera.

+1

Any versioning system that removes subjective criteria is good.  These
debates in interminable and always have been.  Personally I would go
with something even more antiseptic like basing the version on the
year, where year is defined at the 'point of no return' -- going beta
for example.

merlin

* Tom Lane wrote:

> So I think we should solve these problems at a stroke, and save ourselves
> lots of breath in the future, by getting rid of the whole "major major"
> idea and going over to a two-part version numbering scheme.  To be
> specific:
>
> * This year's major release will be 9.6.0, with minor updates 9.6.1,
> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>
> * Next year's major release will be 10.0, with minor updates 10.1,
> 10.2, etc.
>
> * The year after, 11.0.  Etc cetera.

When threaded Postgres is introduced in 2021, the version goes from 13 
to 14. Not quite worthy of that momentous occasion.

Losing a third of the version number means losing the ability to 
differentiate between significant-but-still-incremental improvements and 
(never-again)-stop-the-presses-this-is-great improvements; it's all just 
another major version. (Unless you'd want to jump from 13 to 20, 
effectively making the first digit special.)

Finally, from the, er, visual point of view, 10.1 and 10.2 look good and 
modern, but what about 10.13, 10.17, 10.22?

* Elsewhere, Tom Lane wrote:
> There's also the problem that the current numbering scheme confuses> people who aren't familiar with the project.
Howmany times have> you seen people say "I'm using Postgres 8" or "Postgres 9" when asked> what version they're on?
 

Knowing only the first component would be very nearly as useless with 
two-part version numbers as it is today. The conversation will continue 
just the same:

- "No, what is the exact version?"
- ...
- "There have been several updates for that version since. Can you  please update to the latest one and see if the
problempersists?"
 

In short, -1 from me, but I don't matter much ...


PS: Three of the five 9.x micro versions are prime right now. Any    chance an extra 9.1 release could be arranged?

-- 
Christian

Merlin Moncure <mmoncure@gmail.com> writes:
> Any versioning system that removes subjective criteria is good.  These
> debates in interminable and always have been.

Yeah, I got bored of the topic after about 8.0 ;-)

> Personally I would go
> with something even more antiseptic like basing the version on the
> year, where year is defined at the 'point of no return' -- going beta
> for example.

I still don't like that much, and just thought of another reason why:
it would foreclose doing two major releases per year.  We have debated
that sort of schedule in the past.  While I don't see any reason to
think we'd try to do it in the near future, it would be sad if we
foreclosed the possibility by a poor choice of versioning scheme.
        regards, tom lane

On 05/13/2016 02:00 PM, Tom Lane wrote:
> I still don't like that much, and just thought of another reason why:
> it would foreclose doing two major releases per year.  We have debated
> that sort of schedule in the past.  While I don't see any reason to
> think we'd try to do it in the near future, it would be sad if we
> foreclosed the possibility by a poor choice of versioning scheme.

Well, we have done two major releases in a year before, mostly due to
one release being late and the succeeding one being on time.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

Josh berkus <josh@agliodbs.com> writes:
> On 05/13/2016 02:00 PM, Tom Lane wrote:
>> I still don't like that much, and just thought of another reason why:
>> it would foreclose doing two major releases per year.  We have debated
>> that sort of schedule in the past.  While I don't see any reason to
>> think we'd try to do it in the near future, it would be sad if we
>> foreclosed the possibility by a poor choice of versioning scheme.

> Well, we have done two major releases in a year before, mostly due to
> one release being late and the succeeding one being on time.

What I was on about in this case was the idea of a six-month major release
cycle, which I definitely remember being discussed more-or-less-seriously
in the past.  The question of what to do with a release that slips past
December 31st is distinct from that, though it would also be annoying
if we're using year-based numbers.

An analogy that might get some traction among database geeks is that
version numbers are a sort of surrogate key, and assigning meaning to
surrogate keys is a bad idea.
        regards, tom lane

On Fri, May 13, 2016 at 03:48:39PM -0500, Merlin Moncure wrote:
> Any versioning system that removes subjective criteria is good.  These
> debates in interminable and always have been.  Personally I would go
> with something even more antiseptic like basing the version on the
> year, where year is defined at the 'point of no return' -- going beta
> for example.

Uh, the switch to 8.0 and 9.0 were quite clear discussions, unlike 10.0.

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

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

On Fri, May 13, 2016 at 02:06:26PM -0700, Josh Berkus wrote:
> On 05/13/2016 02:00 PM, Tom Lane wrote:
> > I still don't like that much, and just thought of another reason why:
> > it would foreclose doing two major releases per year.  We have debated
> > that sort of schedule in the past.  While I don't see any reason to
> > think we'd try to do it in the near future, it would be sad if we
> > foreclosed the possibility by a poor choice of versioning scheme.
> 
> Well, we have done two major releases in a year before, mostly due to
> one release being late and the succeeding one being on time.

Uh, guys, we just did it:
9.5    2016-01-079.6    2016-09-??

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

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

On 05/13/2016 02:22 PM, Magnus Hagander wrote:
>

> Using something like <year>.2.0 for the second one in the same year
> could be suggested, but to me that sounds like the worst of both worlds.

The amount of brain cycles, electricity, taxes on internet connectivity 
and transcontinental data spent on the discussion of version numbers 
could have finished the release by now.

How about we just call it 9.6?

I mean we haven't yet actually identified a problem we are trying to 
solve have we?

Sincerely,

JD
-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, May 13, 2016 at 2:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> If we don't want to stick with the current practice of debating when
> to bump the same digit, then let's agree that 10.0 will follow 9.6 and
> after that we'll bump the first digit after X.4, as we did with 7.X
> and 8.X.

It was absolute, utter chance that the 7.x and 8.x series both ended
with .4.  I see no reason to turn that into some kind of standard,
especially when it didn't work like that for 6.x or 9.x. 

<p dir="ltr"><br /> On May 13, 2016 23:27, "Joshua D. Drake" <<a
href="mailto:jd@commandprompt.com">jd@commandprompt.com</a>>wrote:<br /> ><br /> > On 05/13/2016 02:22 PM,
MagnusHagander wrote:<br /> >><br /> >><br /> ><br /> >> Using something like <year>.2.0 for
thesecond one in the same year<br /> >> could be suggested, but to me that sounds like the worst of both
worlds.<br/> ><br /> ><br /> > The amount of brain cycles, electricity, taxes on internet connectivity and
transcontinentaldata spent on the discussion of version numbers could have finished the release by now.<br /> ><br
/>> How about we just call it 9.6?<br /> ><p dir="ltr">I'm pretty sure most people aren't talking about this one
anymore,it's about the next one. I certainly am. <p dir="ltr">9.6 was pretty much decided when we put out the beta,
tbh.<p dir="ltr">/Magnus <br /> 

"Joshua D. Drake" <jd@commandprompt.com> writes:
> I mean we haven't yet actually identified a problem we are trying to 
> solve have we?

The problem I'd like to solve is not having to have this type of
discussion again in future years ...
        regards, tom lane

On Fri, May 13, 2016 at 05:36:50PM -0400, Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > I mean we haven't yet actually identified a problem we are trying to 
> > solve have we?
> 
> The problem I'd like to solve is not having to have this type of
> discussion again in future years ...

If pg_logical and/or more parallelism are in 9.7, there will be no need
for a discussion, just like 8.0 and 9.0 decisions.

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

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

On 05/13/2016 05:12 PM, Tom Lane wrote:
> An analogy that might get some traction among database geeks is that
> version numbers are a sort of surrogate key, and assigning meaning to
> surrogate keys is a bad idea.
>
>             

:-)

I agree year-based numbers will cause us grief.

I don't have any strong opinions about this. It's essentially a 
marketing decision, and I'm happy to leave that to others. If and when 
we do change, I'd like to put in a modest request that we add an extra _ 
to the branch names, like this: REL_10_0_STABLE. That would mean they 
would sort nicely, which would make my life simpler in a few places in 
the buildfarm code. If not, I'd like a little advance notice so I can 
check all the places where we compare branch names.

cheers

andrew

Bruce Momjian <bruce@momjian.us> writes:
> On Fri, May 13, 2016 at 05:36:50PM -0400, Tom Lane wrote:
>> "Joshua D. Drake" <jd@commandprompt.com> writes:
>>> I mean we haven't yet actually identified a problem we are trying to 
>>> solve have we?

>> The problem I'd like to solve is not having to have this type of
>> discussion again in future years ...

> If pg_logical and/or more parallelism are in 9.7, there will be no need
> for a discussion, just like 8.0 and 9.0 decisions.

If you're framing the problem as "how to decide whether next year is 9.7
or 10.0", you're not thinking very far ahead.  If we just leave the
process at status quo, we'll be having the exact same type of discussion
not later than about 10.3, because that's about how long it took for
people to start asking about 9.0:
http://www.postgresql.org/message-id/200704231224.15429.josh@agliodbs.com
or 10.0:
http://www.postgresql.org/message-id/512E8EF8.3000507@agliodbs.com

(I'm not trying to pick on Josh here, those were just the first hits
I found while scanning the -advocacy archives.)

I agree with the opinion that we waste an inordinate amount of effort
on this type of discussion, and have been doing so for a couple of
decades now.  I'd like a permanent fix for that.
        regards, tom lane

Andrew Dunstan <andrew@dunslane.net> writes:
> I don't have any strong opinions about this. It's essentially a 
> marketing decision, and I'm happy to leave that to others. If and when 
> we do change, I'd like to put in a modest request that we add an extra _ 
> to the branch names, like this: REL_10_0_STABLE. That would mean they 
> would sort nicely, which would make my life simpler in a few places in 
> the buildfarm code. If not, I'd like a little advance notice so I can 
> check all the places where we compare branch names.

If we do decide to change the numbering strategy, there are quite a
few small details that probably ought to be fixed while we're at it.
I think it'd be a good idea to start separating "devel" or "betaN"
with a dot, for instance, like "10.devel" not "10devel".  But it's
likely premature to get into those sorts of details, since it's not
clear to me that we have a consensus to change at all.
        regards, tom lane

On 05/13/2016 02:36 PM, Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> I mean we haven't yet actually identified a problem we are trying to
>> solve have we?
>
> The problem I'd like to solve is not having to have this type of
> discussion again in future years ...
>

Amen.

JD

>             regards, tom lane
>


-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

On 14/05/16 09:31, David G. Johnston wrote:
> On Friday, May 13, 2016, Tom Lane <tgl@sss.pgh.pa.us 
> <mailto:tgl@sss.pgh.pa.us>> wrote:
>
>     Robert Haas <robertmhaas@gmail.com <javascript:;>> writes:
>     > On Fri, May 13, 2016 at 2:49 PM, Tom Lane <tgl@sss.pgh.pa.us
>     <javascript:;>> wrote:
>
>     > If we don't want to stick with the current practice of debating when
>     > to bump the same digit, then let's agree that 10.0 will follow
>     9.6 and
>     > after that we'll bump the first digit after X.4, as we did with 7.X
>     > and 8.X.
>
>     It was absolute, utter chance that the 7.x and 8.x series both ended
>     with .4.  I see no reason to turn that into some kind of standard,
>     especially when it didn't work like that for 6.x or 9.x.
>
>
> The underlying premise, for me, of choosing .4 or .5  was that 
> presently we discontinue support after 5 years/releases.  A new .0 
> would come out just as we discontinue the previous .0
>
> As an added idea, if switching to major.patch, would be to make 10.0.x 
> but then go to 11.x. Though that's somewhat easier cognitively it 
> would probably be harder for developers that just ripping off the bandaid.
>
> David J.
>
I think the idea of incrementing the first digit when ever the last 
major version reaches EOL, is probably the best compromise. If that was 
adopted, then people could plan changes that triggered major breakage in 
established usage accordingly.

I like the version 'x.y.z' approach, where 'z' mostly means bug fixes 
and minor tweaks, 'y' has more significant enhancements, and 'x' may 
mean major breakages.  Lets not go down the Mozilla version inflation route.

For now, probably best if we have 9.5.n, 9.6.n, 10.0.n (where obviously 
n starts at zero for each series!).


Cheers,

Gavin

On Fri, May 13, 2016 at 9:15 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> Man, I hate version number inflation.  I'm running Firefox 45.0.2, and
> I think that's crazy.  It hit 1.0 when were at aversion 7.4!

I don't see what's wrong with large numbers, it's not like there's a
shortage of numbers.

And for what it's worth the only reason we we were on 7.x at all is
that we went from 1.0.5 to 6.0 -- precisely because it was our sixth
release. If we had kept on that track we would have been on the same
plan Tom is proposing now.

One alternative to really drive home that the new scheme is a change
to people would be to do the same again. By my count 9.6 will be our
28th release. We could jump from 9.6 to Postgres 29.0. (That would
have the side benefit that we could retroactively number all the
previous releases in a consistent way if we wanted to)





-- 
greg

> On May 13, 2016, at 11:31 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> Josh berkus wrote:
>
>> Anyway, can we come up with a consensus of some minimum changes it will
>> take to make the next version 10.0?
>
> I think the next version should be 10.0 no matter what changes we put
> in.

-1

If I understand correctly, changing the micro version means that one or more
bugs have been fixed, but that the on-disk representation has not changed.  So
if I am running 9.3.2, I am at liberty to upgrade to 9.3.3 without a dump and
restore.

If the minor number has changed, new features have been added that require
a dump and restore.  As such, on 9.3.2, I would not be at liberty to upgrade to
9.4.0 without some extra effort.

A major number change should indicate that something even bigger than on-disk
compatibility has changed, such as a change that precludes even a dump and
restore from working, or that breaks network communication protocols, etc.

Any project that starts inflating its numbering scheme sends a message to
users of the form, "hey, we've just been taken over by marketing people, and
software quality will go down from now on."

mark

Mark Dilger <hornschnorter@gmail.com> writes:
> A major number change should indicate that something even bigger than on-disk
> compatibility has changed, such as a change that precludes even a dump and
> restore from working, or that breaks network communication protocols, etc.

If that were the standard, we'd never have bumped the major version at
all, and would still be on 4.something (or whatever Berkeley was using
when they tossed it over the wall; I'm not too clear on whether there was
ever a 5.x release).  I can't imagine that we'd ever intentionally break
dump/restore compatibility.  While we have changed the network protocol,
and likely will again, we kept on supporting the old protocol alongside,
and almost certainly would do so again.  There are too many compatibility
constraints that we have to meet in order to be a usable database at all,
so we're never going to just blow it up and start over.

> Any project that starts inflating its numbering scheme sends a message to
> users of the form, "hey, we've just been taken over by marketing people, and
> software quality will go down from now on."

I don't think this is about version number inflation, but actually more
the opposite.  What you're calling the major number is really a marketing
number.  There is not a technical distinction between major releases where
we choose to bump the first number and those where we choose to bump the
second.  It's all about marketing.  So to me, merging those numbers would
be an anti-marketing move.  I think it's a good move: it would be more
honest and transparent about what the numbers mean, not less so.
        regards, tom lane

> On May 13, 2016, at 5:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Mark Dilger <hornschnorter@gmail.com> writes:
>> A major number change should indicate that something even bigger than on-disk
>> compatibility has changed, such as a change that precludes even a dump and
>> restore from working, or that breaks network communication protocols, etc.
>
> If that were the standard, we'd never have bumped the major version at
> all, and would still be on 4.something (or whatever Berkeley was using
> when they tossed it over the wall; I'm not too clear on whether there was
> ever a 5.x release).  I can't imagine that we'd ever intentionally break
> dump/restore compatibility.  While we have changed the network protocol,
> and likely will again, we kept on supporting the old protocol alongside,
> and almost certainly would do so again.  There are too many compatibility
> constraints that we have to meet in order to be a usable database at all,
> so we're never going to just blow it up and start over.

Well, those are just examples.  Other candidate examples would be dropping
datatypes such as 'money' that were maybe not a good idea to begin with,
or somehow ditching the 'timestamp' vs. 'timestamptz' distinction, or
changing to 64-bit Oids, such that software that interacts with postgresql
has to change accordingly.  Another such idea would be supporting 64-bit
varlena lengths and dropping large object support.  Another would be
dropping support for older communication protocols whose presence in the
server out of the box makes the server a security vulnerability.  (I am not
asserting the presence of such vulnerabilities, but just speculating on the
possibility that such vulnerabilities might be discovered in the future that
make it useful to ditch older, insecure protocols.)

I suspect other folks could add lots of other stuff to this list.


>> Any project that starts inflating its numbering scheme sends a message to
>> users of the form, "hey, we've just been taken over by marketing people, and
>> software quality will go down from now on."
>
> I don't think this is about version number inflation, but actually more
> the opposite.  What you're calling the major number is really a marketing
> number.  There is not a technical distinction between major releases where
> we choose to bump the first number and those where we choose to bump the
> second.  It's all about marketing.  So to me, merging those numbers would
> be an anti-marketing move.  I think it's a good move: it would be more
> honest and transparent about what the numbers mean, not less so.

I find your argument persuasive if there is no possibility of ever needing
a major number to bump.  But if anything like what I described above could
someday happen, it seems the major.minor.micro format would come in
handy.  Perhaps the problem (from my perspective) is that the major number
has been used for purely marketing purposes in the past, and I've tried to
avert my eyes to that.  But going forward, my vote (worth less than half a
cent I'm sure) is to stop using it for marketing reasons.

mark

On 05/13/2016 05:22 PM, Mark Dilger wrote:
>>> >> Any project that starts inflating its numbering scheme sends a message to
>>> >> users of the form, "hey, we've just been taken over by marketing people, and
>>> >> software quality will go down from now on."
>> > 
>> > I don't think this is about version number inflation, but actually more
>> > the opposite.  What you're calling the major number is really a marketing
>> > number.  There is not a technical distinction between major releases where
>> > we choose to bump the first number and those where we choose to bump the
>> > second.  It's all about marketing.  So to me, merging those numbers would
>> > be an anti-marketing move.  I think it's a good move: it would be more
>> > honest and transparent about what the numbers mean, not less so.
> I find your argument persuasive if there is no possibility of ever needing
> a major number to bump.  But if anything like what I described above could
> someday happen, it seems the major.minor.micro format would come in
> handy.  Perhaps the problem (from my perspective) is that the major number
> has been used for purely marketing purposes in the past, and I've tried to
> avert my eyes to that.  But going forward, my vote (worth less than half a
> cent I'm sure) is to stop using it for marketing reasons.

Per a long discussion on -advocacy, nobody has any specific plans to do
substantial breakage of backwards compatibility.  Theoretically we might
someday want to change the on-disk format, but nobody has plans to do so
in the immediate future.  How long should we hold out for that?  Until 9.27?

And I don't find dropping the "money" type to be substantial breakage.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

> On May 13, 2016, at 5:49 PM, Josh berkus <josh@agliodbs.com> wrote:
>
> On 05/13/2016 05:22 PM, Mark Dilger wrote:
>>>>>> Any project that starts inflating its numbering scheme sends a message to
>>>>>> users of the form, "hey, we've just been taken over by marketing people, and
>>>>>> software quality will go down from now on."
>>>>
>>>> I don't think this is about version number inflation, but actually more
>>>> the opposite.  What you're calling the major number is really a marketing
>>>> number.  There is not a technical distinction between major releases where
>>>> we choose to bump the first number and those where we choose to bump the
>>>> second.  It's all about marketing.  So to me, merging those numbers would
>>>> be an anti-marketing move.  I think it's a good move: it would be more
>>>> honest and transparent about what the numbers mean, not less so.
>> I find your argument persuasive if there is no possibility of ever needing
>> a major number to bump.  But if anything like what I described above could
>> someday happen, it seems the major.minor.micro format would come in
>> handy.  Perhaps the problem (from my perspective) is that the major number
>> has been used for purely marketing purposes in the past, and I've tried to
>> avert my eyes to that.  But going forward, my vote (worth less than half a
>> cent I'm sure) is to stop using it for marketing reasons.
>
> Per a long discussion on -advocacy, nobody has any specific plans to do
> substantial breakage of backwards compatibility.  Theoretically we might
> someday want to change the on-disk format, but nobody has plans to do so
> in the immediate future.  How long should we hold out for that?  Until 9.27?
>
> And I don't find dropping the "money" type to be substantial breakage.

If minor number bumps mean, "dump and restore is necessary, but client
programs are guaranteed to still work", then dropping the "money" type
is a different kind of action.  Maybe you don't think it matters much, but
for somebody who is using it in a client application, that matters.  Likewise,
somebody who has a struct in a client program that expects Oid to fit into
32 bits *needs* to go through their client programs if Oid ever gets changed
to 64 bit.  (Pigs will probably fly first, but just for instance.)

I'm not advocating any of these changes today.  I just think they are different
kinds of changes from adding new functions while leaving all old functions
in tact.  As cool as parallel query is (and I'd happily buy Robert or Amit a
beer) it doesn't break any functionality in client applications that ignore it,
so far as I can see.  Using parallel query as a motivation for increasing the
major number stems from a marketing instinct, not from sound engineering
practices.

Now that I've said that, I'll sit back and wait for the REL10_0_DEVEL
branch to appear in the repo.

mark

> On May 13, 2016, at 6:33 PM, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Fri, May 13, 2016 at 7:32 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>
> Any project that starts inflating its numbering scheme sends a message to
> users of the form, "hey, we've just been taken over by marketing people, and
> software quality will go down from now on."
>
> ​Tom brought up my own thoughts on the rest - but, really, this is a cynical way of looking at things.

Every company I have worked for that has been taken over by pointy haired
bosses has almost immediately begun playing games with the version numbers,
product names, etc, and dropped the focus on quality, performance, bug fixes,
etc.  I don't expect that from the postgresql community, but I find discussion
on the mailing lists about using a "wow, 10.x.x release! how amazing" marketing
line rather crass.  I doubt many people in the tech industry generally feel all
that differently about it.  I've never worked with a programmer or DBA who was
impressed with these kinds of version number bumps.

I fully agree mine is a cynical point of view.

My main concern is that a commitment to never, ever break backwards
compatibility is a commitment to obsolescence.  It therefore makes sense to
reserve room in the numbering scheme to be clear and honest about when
backwards compatibility has been broken.  The major number is the normal
place to do that.

Just my .00002 cents.

mark

> On May 13, 2016, at 8:26 PM, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Fri, May 13, 2016 at 10:18 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence.
>
> ​​You started this sub-thread with:
>
> "If I understand correctly..."
>
> ​I'm not sure that you do...​
>
> Our scheme is, in your terms, basically:
>
> <major>.micro
>
> where <major> is a decimal.
>
> You cannot reason about the whole and fraction portions of the decimal independently.

There is no point in having them as separate parts of the version number
unless you can do precisely that.  If the only difference between choosing 9.7.0
vs. 10.0.0 is that you consulted a numerologist who moonlights as an astrologer,
then, yes, you can't tell anything from the first number independent from
the second.  I was simply arguing against the numerology/astrology approach
to version numbering.  The only other way out of the numerology/astrology
approach is the one Tom Lane suggested, and that you seem to support.

This whole conversation makes me think the community has done a poor job
of communicating the nature of the (major,minor) portion of the (major,minor,micro)
numbering scheme.  I always assumed it was more respectable that it now
appears to have been.

mark

On 14/05/16 02:00, Tom Lane wrote:

[...]
> I don't think this is about version number inflation, but actually more
> the opposite.  What you're calling the major number is really a marketing
> number.  There is not a technical distinction between major releases where
> we choose to bump the first number and those where we choose to bump the
> second.  It's all about marketing.  So to me, merging those numbers would
> be an anti-marketing move.  I think it's a good move: it would be more
> honest and transparent about what the numbers mean, not less so.
    If having two "major" numbers is a marketing game, and if it works 
in such a way, I'd immediately say let's keep it. Decisions like the one 
debated here should be driven more from what is going to help user 
adoption rather than -hackers personal taste. BTW, none of these 
approaches seem dishonest to me.
    Having said that, I believe having a single major number is a more 
effective marketing. Non major-major versions may make the release look 
like a "probably not worth" upgrade. People may hold their breath until 
a major-major upgrade, specially if people support this idea in forums 
like saying: "10.0 will come with amazing features, because version is 
bumped from 9.6".
    So +1 to call 10.0 the next version and 11.0 the one after that.
    Álvaro

-- 
Álvaro Hernández Tortosa


-----------
8Kdata

Re: Álvaro Hernández Tortosa 2016-05-14 <5736F966.3040404@8kdata.com>
>     Having said that, I believe having a single major number is a more
> effective marketing. Non major-major versions may make the release look like
> a "probably not worth" upgrade. People may hold their breath until a
> major-major upgrade, specially if people support this idea in forums like
> saying: "10.0 will come with amazing features, because version is bumped
> from 9.6".
> 
>     So +1 to call 10.0 the next version and 11.0 the one after that.

+1.

Another data point: Debian did exactly this x.y.z -> x.y switch (with
exactly the same major/minor version number semantics re major/minor
upgrades) a few years ago [*], and it was a real relief. "Debian 9"
just sounds so much better than "Debian 9.6".

IMHO getting rid of the problem that people are always saying "I'm
using Postgres 9" when asked about the major version should be enough
reason to change to a x.y scheme.

Christoph

[*] There was a period of two releases where we bumped the x and y was
kept 0, before the y was ultimately dropped.
(3.0 - 3.1 - 4.0 - 5.0 - 6.0 - 7 - 8)

On Fri, May 13, 2016 at 8:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Any project that starts inflating its numbering scheme sends a message to
>> users of the form, "hey, we've just been taken over by marketing people, and
>> software quality will go down from now on."
>
> I don't think this is about version number inflation, but actually more
> the opposite.  What you're calling the major number is really a marketing
> number.  There is not a technical distinction between major releases where
> we choose to bump the first number and those where we choose to bump the
> second.  It's all about marketing.  So to me, merging those numbers would
> be an anti-marketing move.  I think it's a good move: it would be more
> honest and transparent about what the numbers mean, not less so.

"Marketing" and "honesty" are not antonyms, and thinking that
marketing is unimportant for the success of the project is not
correct.

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

On Fri, May 13, 2016 at 11:39 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> There is a long-running thread on pgsql-hackers on whether 9.6 should
>> instead be called 10.0.
>
> First I've seen it mentioned here.
>
> I think you are just about exactly one week too late to bring this up.
> Once we've shipped a beta, rebranding is way too confusing.

So, not that it makes any difference at this point, but this seems to
fly in the face of what you said before.

http://www.postgresql.org/message-id/24567.1456864829@sss.pgh.pa.us

Unless you thought that beta wasn't going to be out until the fall.

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

On 05/14/2016 07:08 AM, Robert Haas wrote:
> On Fri, May 13, 2016 at 8:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Any project that starts inflating its numbering scheme sends a message to
>>> users of the form, "hey, we've just been taken over by marketing people, and
>>> software quality will go down from now on."
>>
>> I don't think this is about version number inflation, but actually more
>> the opposite.  What you're calling the major number is really a marketing
>> number.  There is not a technical distinction between major releases where
>> we choose to bump the first number and those where we choose to bump the
>> second.  It's all about marketing.  So to me, merging those numbers would
>> be an anti-marketing move.  I think it's a good move: it would be more
>> honest and transparent about what the numbers mean, not less so.
>
> "Marketing" and "honesty" are not antonyms, and thinking that
> marketing is unimportant for the success of the project is not
> correct.

+1

JD



-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

El 13/05/16 a las 15:31, Alvaro Herrera escribió:
> Josh berkus wrote:
>  
>> Anyway, can we come up with a consensus of some minimum changes it will
>> take to make the next version 10.0?
> 
> I think the next version should be 10.0 no matter what changes we put
> in.

+1

And another +1 on Tom's opinion on it being too late after beta1 has
been released.

-- 
Martín Marqués                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.

It will hopefully both end these discussions and remove the confusion 
the current versioning scheme has (I too heard way to many times about 
people using postgres8 or postgres9).

For those saying this is version inflation. I don't see the problem, we 
are project with long history, which releases major version every year, 
I don't see why version number shouldn't reflect that.

About changing first digit only when we break compatibility with 
applications for example by removing money type. We do have app breaking 
incompatibilities in almost every major version so in effect we'd have 
to bump the first digit every time anyway if we went with that schema (I 
still remember working on db that was kept on 8.3 till EOL just because 
we changes hashtext implementation, or db which was kept back because of 
removal plgpsql rename clause where nobody wanted to rewrite couple 
thousand function which used it and there are many examples like that).

--   Petr Jelinek                  http://www.2ndQuadrant.com/  PostgreSQL Development, 24x7 Support, Training &
Services

El 13/05/16 a las 15:36, Josh berkus escribió:
> On 05/13/2016 11:31 AM, Alvaro Herrera wrote:
>> Josh berkus wrote:
>>  
>>> Anyway, can we come up with a consensus of some minimum changes it will
>>> take to make the next version 10.0?
>>
>> I think the next version should be 10.0 no matter what changes we put
>> in.
>>
> 
> Well, if we adopt 2-part version numbers, it will be.  Maybe that's the
> easiest thing?  Then we never have to have this discussion again, which
> certainly appeals to me ...

Wasn't there some controversy about switching to major.minor versioning
this in -advocacy?

http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5f78@biglumber.com

IMO, this versioning is pretty good and people understand it well, with
the other will be using postgres 13 by 2020, which isn't far away. ;)

-- 
Martín Marqués                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Fri, May 13, 2016 at 05:31:00PM -0400, David G. Johnston wrote:
> The underlying premise, for me, of choosing .4 or .5  was that presently we
> discontinue support after 5 years/releases.  A new .0 would come out just
> as we discontinue the previous .0

Well maybe the 5 year support cycle would be nice to encode, but how is
.0 different from .1 then?  You make sound like .0 would be similar to
Ubuntu's LTS which is not the case, unless you want to propose that only
.0 releases get 5 years and not the in-betweens? That'd be a shame.

Michael

On Fri, May 13, 2016 at 08:55:20PM -0400, David G. Johnston wrote:
> The opinion seems to be that major.0 is some kind of magic incantation in
> the broader world of users...

From my reading of the thread, while certainly that is the general
definition of a .0, having infrequent .0 releases is not very practical
for PostgreSQL because the major versions are not that different from
each other and all are treated the same development-wise. So it would be
a huge drain on the project to discuss which major version should be a
.0 unless planning towards them steps up significantly.

So I think the (slight) consensus is more that all major versions are
mostly equal and hence only one version number is needed.


Michael

On 05/13/2016 07:18 PM, Mark Dilger wrote:
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence.  It therefore makes sense to
> reserve room in the numbering scheme to be clear and honest about when
> backwards compatibility has been broken.  The major number is the normal
> place to do that.

The problem with that idea is that *minor* backwards compatibility
breakage is much more likely in each-and-every version than major
breakage is at any time in the foreseeable future.  The last major
breakage we really had was version 8.3, which if we'd been going by
compatibility should have been 9.0 (also for other reasons).

And if we adopt the "backwards compatibility" approach, then we'll just
be switching from the argument we're having now to the argument of "is
this enough breakage to rate a .0?  Yes/No?".  Which argument will be
just as long as this one.

So, my vote is now +1 to go to the 2-part numbering scheme.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160


> Wasn't there some controversy about switching to major.minor versioning
> this in -advocacy?
>
> http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5f78@biglumber.com

I proposed in that thread that we always increment the first number, 
never increment the second number, and increment the third exactly as we do 
now for bugfix releases.

I think moving to a two-number format is a mistake: what exactly will 
PQserverVersion() return in that case? But I understand people have a hard 
time swallowing the "never change the middle number" portion of this idea.

Thus, here's a slight variation on that theme: what if we simply reversed the 
expectations of bumping the first number, and put the onus on people to 
change the *middle* number? Thus, the next release by default will be 10.0.0, 
the one after that will be by default 11.0.0, and so on. We can reserve the 
middle number for "lesser" releases - which may never happen - but at least 
we will have a mechanism to provide for them. So rather than the current spate 
of messages like this:

"This should be called 12.0 because of cool feature X and reason Y"

we would get the rare message like this:

"We don't really have much for this release, maybe it should just be 11.1?"


- -- 
Greg Sabino Mullane greg@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201605142247
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlc34/UACgkQvJuQZxSWSsgQLgCeJS9v69R5C3BJxNy2ih1P2Tk8
xngAn0UQoSn6y3iOwMr5aHSKzuBh+3Xn
=wzw4
-----END PGP SIGNATURE-----

"Greg Sabino Mullane" <greg@turnstep.com> writes:
> I think moving to a two-number format is a mistake: what exactly will 
> PQserverVersion() return in that case?

For, say, 10.2 it would be 100002, equivalent to 10.0.2 under old style.

We could redefine it as being major plus four-digit minor, really.
Under the current maintenance scheme we never get anywhere near minor
release 99 before a branch dies ... but having some more breathing room
there would not be a bad thing.
        regards, tom lane

On Sat, May 14, 2016 at 7:51 PM, Greg Sabino Mullane <greg@turnstep.com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
>> Wasn't there some controversy about switching to major.minor versioning
>> this in -advocacy?
>>
>> http://www.postgresql.org/message-id/ee13fd2bb44cb086b457be34e81d5f78@biglumber.com
>
> I proposed in that thread that we always increment the first number,
> never increment the second number, and increment the third exactly as we do
> now for bugfix releases.

I like this idea, roughly in line with SemVer.

There are lots of improvement which get done to in-memory data
structures that wouldn't require a pg_dump/pg_upgrade, which could in
principle be ported into prior major versions if we had the resources
(reviewing, testing, packaging) to do it, with an increase in the
middle number.  Maybe we will never find the resources to do that, but
why should that assumption get baked into the numbering scheme?

Cheers,

Jeff

Jeff Janes <jeff.janes@gmail.com> writes:
> There are lots of improvement which get done to in-memory data
> structures that wouldn't require a pg_dump/pg_upgrade, which could in
> principle be ported into prior major versions if we had the resources
> (reviewing, testing, packaging) to do it, with an increase in the
> middle number.  Maybe we will never find the resources to do that, but
> why should that assumption get baked into the numbering scheme?

If we were to do that today, it'd just be an increase in the minor number.
I don't see why we'd need to change that approach.  The real blocking
factors there are about manpower and stability of the resulting code, not
about whether you need some special version numbering to describe it.
        regards, tom lane

On Sun, May 15, 2016 at 11:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Greg Sabino Mullane" <greg@turnstep.com> writes:
>> I think moving to a two-number format is a mistake: what exactly will
>> PQserverVersion() return in that case?
>
> For, say, 10.2 it would be 100002, equivalent to 10.0.2 under old style.
>
> We could redefine it as being major plus four-digit minor, really.
> Under the current maintenance scheme we never get anywhere near minor
> release 99 before a branch dies ... but having some more breathing room
> there would not be a bad thing.

Perhaps that would be a good topic for the developer meeting in
Ottawa? That's just in two days, so it looks like a good timing.
-- 
Michael

On 14/05/16 20:02, Petr Jelinek wrote:
> +1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.
>
> It will hopefully both end these discussions and remove the confusion 
> the current versioning scheme has (I too heard way to many times about 
> people using postgres8 or postgres9).
    Even worse: I've been told that a company was using "PostgreSQL 
8.5" ^_^

    Álvaro

-- 
Álvaro Hernández Tortosa


-----------
8Kdata

On Sun, May 15, 2016 at 2:29 PM, Álvaro Hernández Tortosa <aht@8kdata.com> wrote:

On 14/05/16 20:02, Petr Jelinek wrote:

+1 for going with 10.0 after 9.6 and 11.0 afterwards, etc.

It will hopefully both end these discussions and remove the confusion the current versioning scheme has (I too heard way to many times about people using postgres8 or postgres9).

    Even worse: I've been told that a company was using "PostgreSQL 8.5" ^_^

That's not necessarily the version numbers fault. That's them using an alpha version.. (Yes, I've run into a customer just a couple of years ago that were still on 8.5 alpha) 

-- 
Álvaro Hernández Tortosa


-----------
8Kdata

On 5/13/16 5:01 PM, Tom Lane wrote:
> If we do decide to change the numbering strategy, there are quite a
> few small details that probably ought to be fixed while we're at it.
> I think it'd be a good idea to start separating "devel" or "betaN"
> with a dot, for instance, like "10.devel" not "10devel".  But it's
> likely premature to get into those sorts of details, since it's not
> clear to me that we have a consensus to change at all.

It would be interesting to actually release snapshots after commit 
fests, ie: 10.dev.0, 10.dev.1, etc.

And +1 for ditching major.major.minor in favor of major.minor.0. It's 
high time we stop this silliness.

IMHO the beginning of parallelism that we have now is more than enough 
to justify 10.0, but that consideration pales compared to fixing the 
version numbering system itself.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

On Sat, May 14, 2016 at 1:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> If that were the standard, we'd never have bumped the major version at
> all, and would still be on 4.something (or whatever Berkeley was using
> when they tossed it over the wall; I'm not too clear on whether there was
> ever a 5.x release).

I thought the idea was that Berkeley tossed an source tree over the
wall with no version number and then the first five releases were
Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2,
Postgres95 1.0.9. Then the idea was that PostgreSQL 6.0 was the sixth
major release counting those as the first five releases.

-- 
greg

On 5/16/16 9:53 AM, Greg Stark wrote:
> On Sat, May 14, 2016 at 1:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> If that were the standard, we'd never have bumped the major version at
>> all, and would still be on 4.something (or whatever Berkeley was using
>> when they tossed it over the wall; I'm not too clear on whether there was
>> ever a 5.x release).
>
> I thought the idea was that Berkeley tossed an source tree over the
> wall with no version number and then the first five releases were
> Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2,
> Postgres95 1.0.9. Then the idea was that PostgreSQL 6.0 was the sixth
> major release counting those as the first five releases.

The last release out of Berkeley was 4.2.  Then Postgres95 was "5", and 
then PostgreSQL started at 6.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 5/16/16 9:53 AM, Greg Stark wrote:
>> I thought the idea was that Berkeley tossed an source tree over the
>> wall with no version number and then the first five releases were
>> Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2,
>> Postgres95 1.0.9. Then the idea was that PostgreSQL 6.0 was the sixth
>> major release counting those as the first five releases.

> The last release out of Berkeley was 4.2.

Correct --- I have a copy of that tarball.

> Then Postgres95 was "5", and then PostgreSQL started at 6.

I wasn't actually around at the time, but our commit history starts
with this:

Author: Marc G. Fournier <scrappy@hub.org>
Branch: master Release: REL6_1 [d31084e9d] 1996-07-09 06:22:35 +0000
   Postgres95 1.01 Distribution - Virgin Sources

The first mention of 6.anything is here:

Author: Bruce Momjian <bruce@momjian.us>
Branch: master Release: REL6_1 [a2b7f6297] 1996-12-28 02:01:58 +0000
   Updated changes for 6.0.

I see no references in the commit history to 5.anything, but there
are some references like this:

Author: Marc G. Fournier <scrappy@hub.org>
Branch: master Release: REL6_1 [491b9b89c] 1996-08-26 20:38:52 +0000
   The patch that is applied at the end of the email makes sure that these   conditions are always met. The patch can
beapplied to any version   of Postgres95 from 1.02 to 1.05. After applying the patch, queries   using indices on bpchar
andvarchar fields should (hopefully ;-) )   always return the same tuple set regardless to the fact whether   indices
areused or not.   Submitted by: Gerhard Reithofer <tbr_laa@AON.AT>
 

So I think that the Postgres95 releases were retrospectively redefined as
being the "5.x" series, but no release was ever made with such a number.
        regards, tom lane

On Sat, May 14, 2016 at 8:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> There are lots of improvement which get done to in-memory data
>> structures that wouldn't require a pg_dump/pg_upgrade, which could in
>> principle be ported into prior major versions if we had the resources
>> (reviewing, testing, packaging) to do it, with an increase in the
>> middle number.  Maybe we will never find the resources to do that, but
>> why should that assumption get baked into the numbering scheme?
>
> If we were to do that today, it'd just be an increase in the minor number.
> I don't see why we'd need to change that approach.

We've rejected back-patching such improvements in the past on the
grounds that it was at least theoretically possible that it would
negatively affect someone, even if it were a win overall for most
people, and users shouldn't be forced to adopt that risk in order to
get security or corruption bug fixes that go into the minor number
increments.

> The real blocking
> factors there are about manpower and stability of the resulting code, not
> about whether you need some special version numbering to describe it.

If we did overcome the man-power and stability problems, we would
certain run into the version numbering one pretty quickly, under both
the existing versioning system and the two-part system.

And I don't think that using something at least vaguely like SemVer is
really "special", if anything it is less special than either the
existing or the dominant proposal.

Cheers,

Jeff

On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
> On 14 May 2016 at 02:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > * This year's major release will be 9.6.0, with minor updates 9.6.1,
> > 9.6.2, etc.  It's too late to do otherwise for this release cycle.
> >
> > * Next year's major release will be 10.0, with minor updates 10.1,
> > 10.2, etc.
> >
> > * The year after, 11.0.  Etc cetera.
> >
> >
> Yes. Please!
> 
> I get tired of explaining to people that PostgreSQL "9.x" isn't a thing,
> that yes, 9.3 and 9.4 really _do_ have incompatible data directories and
> replication protocols, and that when the docs say "major version" they
> don't mean "major version as you might actually expect" but "first two
> version number parts".
> 
> Lets get rid of this user-baffling wart.

Hear, hear!

Sadly, we're too late for 9.6, but we can start with 10.0 and finish
this silliness once and for good.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

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

On 5/17/16 10:51 AM, David Fetter wrote:
> On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:>> On 14 May 2016 at 02:49, Tom Lane <tgl@sss.pgh.pa.us>
wrote:>>>* This year's major release will be 9.6.0, with minor updates 9.6.1,>>> 9.6.2, etc.  It's too late to do
otherwisefor this release cycle.>>>>>> * Next year's major release will be 10.0, with minor updates 10.1,>>> 10.2,
etc.>>>>>>* The year after, 11.0.  Etc cetera.>>>>>>>> Yes. Please!>> Hear, hear!>> Sadly, we're too late for 9.6, but
wecan start with 10.0 and finish> this silliness once and for good.
 

+1!

-- 
-David
david@pgmasters.net

On 17 May 2016 at 10:37, David Steele <david@pgmasters.net> wrote:
> On 5/17/16 10:51 AM, David Fetter wrote:
>
>> On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
>>> On 14 May 2016 at 02:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> * This year's major release will be 9.6.0, with minor updates 9.6.1,
>>>> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>>>>
>>>> * Next year's major release will be 10.0, with minor updates 10.1,
>>>> 10.2, etc.
>>>>
>>>> * The year after, 11.0.  Etc cetera.
>>>>
>>>>
>>> Yes. Please!
>>
>> Hear, hear!
>>
>> Sadly, we're too late for 9.6, but we can start with 10.0 and finish
>> this silliness once and for good.
>
> +1!
>

+1

-- 
Jaime Casanova                      www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On Tue, May 17, 2016 at 12:45 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 14 May 2016 at 02:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> * This year's major release will be 9.6.0, with minor updates 9.6.1,
>> 9.6.2, etc.  It's too late to do otherwise for this release cycle.
>>
>> * Next year's major release will be 10.0, with minor updates 10.1,
>> 10.2, etc.
>>
>> * The year after, 11.0.  Etc cetera.
>>
>
> Yes. Please!
>
> I get tired of explaining to people that PostgreSQL "9.x" isn't a thing,
> that yes, 9.3 and 9.4 really _do_ have incompatible data directories and
> replication protocols, and that when the docs say "major version" they don't
> mean "major version as you might actually expect" but "first two version
> number parts".
>
> Lets get rid of this user-baffling wart.

Agreed.  What's been nagging me is what the impacts to users could be.
I just stumbled across some code that *could* have been broken, but by
sheer luck it's safe:
 /* only postgres 9.3+ supports row count from 'COPY' */ IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC
>=9.3 THEN   GET DIAGNOSTICS _RowCount = ROW_COUNT; ELSE   _RowCount := (LineCount(_ScratchFileName,     (SELECT
WorkFolderFROM CDSControl)))::BIGINT - 1; END IF;
 

LineCount() is a pl/sh wrapper to 'wc -l' that supports this wrapper
to COPY so that it always gives a count of rows loaded.  I guess this
is a pretty hacky way of doing version checks inside of SQL but I
suppose changing the structure of the version number might break
similar approaches to parsing the string.  This regex would in fact
continue to work properly, but it did raise some alarm bells.

Looking ahad, IMO we could:

A) make a variant of version() that returns major/minor/bugfix as
separate fields with minor being set to 0 for all released versions
10.0 and beyond.  We could then add a NOTE to the version function and
other places suggesting to use that instead for 9.6.

B) Preserve x.y.z as returned by version() and show server_version for
those usages only, with 'y' being always 0 for 10.0 and beyond.  For
all other purposes (marketing/documentation/etc) that structure would
*not* be preserved, and we would put notes in the documentation
describing why the extra digit is there.

C) Do neither A or B, and let our users discover such issues on their own.

merlin

On 6/13/16 2:12 PM, Merlin Moncure wrote:
> A) make a variant of version() that returns major/minor/bugfix as
> separate fields with minor being set to 0 for all released versions
> 10.0 and beyond.  We could then add a NOTE to the version function and
> other places suggesting to use that instead for 9.6.
>
> B) Preserve x.y.z as returned by version() and show server_version for
> those usages only, with 'y' being always 0 for 10.0 and beyond.  For
> all other purposes (marketing/documentation/etc) that structure would
> *not* be preserved, and we would put notes in the documentation
> describing why the extra digit is there.
>
> C) Do neither A or B, and let our users discover such issues on their own.

D) Add a version function to 10.0 that returns both parts separately.

My vote is D. Parsing version() output is a wart, but coming out with a 
split output version of that in 9.6 that still has to support 3 numbers 
would also be a wart. We've lived with the parsing wart this long, so 
lets just add an explicit output version to 10.0.

Any ideas on naming for such a function? version_detail()? I suppose 
while we're at this we might as well provide the compile details as well.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

On Tue, Jun 14, 2016 at 3:46 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 6/13/16 2:12 PM, Merlin Moncure wrote:
>>
>> A) make a variant of version() that returns major/minor/bugfix as
>> separate fields with minor being set to 0 for all released versions
>> 10.0 and beyond.  We could then add a NOTE to the version function and
>> other places suggesting to use that instead for 9.6.
>>
>> B) Preserve x.y.z as returned by version() and show server_version for
>> those usages only, with 'y' being always 0 for 10.0 and beyond.  For
>> all other purposes (marketing/documentation/etc) that structure would
>> *not* be preserved, and we would put notes in the documentation
>> describing why the extra digit is there.
>>
>> C) Do neither A or B, and let our users discover such issues on their own.
>
>
> D) Add a version function to 10.0 that returns both parts separately.
>
> My vote is D. Parsing version() output is a wart, but coming out with a
> split output version of that in 9.6 that still has to support 3 numbers
> would also be a wart. We've lived with the parsing wart this long, so lets
> just add an explicit output version to 10.0.
>
> Any ideas on naming for such a function? version_detail()? I suppose while
> we're at this we might as well provide the compile details as well.

This seems kind of silly, because anybody who is writing code that
might have to run against an existing version of the database won't be
able to use it.  The one thing that absolutely has to be cross-version
is the method of determining which version you're running against.

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

On 06/14/2016 12:46 PM, Jim Nasby wrote:

> Any ideas on naming for such a function? version_detail()? I suppose
> while we're at this we might as well provide the compile details as well.

version(detail) or version(verbose)

JD

-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

On 6/14/16 3:01 PM, Robert Haas wrote:
>> D) Add a version function to 10.0 that returns both parts separately.
>> >
>> > My vote is D. Parsing version() output is a wart, but coming out with a
>> > split output version of that in 9.6 that still has to support 3 numbers
>> > would also be a wart. We've lived with the parsing wart this long, so lets
>> > just add an explicit output version to 10.0.
>> >
>> > Any ideas on naming for such a function? version_detail()? I suppose while
>> > we're at this we might as well provide the compile details as well.
> This seems kind of silly, because anybody who is writing code that
> might have to run against an existing version of the database won't be
> able to use it.  The one thing that absolutely has to be cross-version
> is the method of determining which version you're running against.

We're talking about a function that doesn't currently exist anyway. So 
no matter what, you won't be able to use it if you're interested in 
<10.0 (or <9.6 if we went with one of the other proposals).

Unless folks were thinking this is something that would be backpatched?
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 6/14/16 3:01 PM, Robert Haas wrote:
>> This seems kind of silly, because anybody who is writing code that
>> might have to run against an existing version of the database won't be
>> able to use it.  The one thing that absolutely has to be cross-version
>> is the method of determining which version you're running against.

> We're talking about a function that doesn't currently exist anyway.

Huh?  We're talking about PQserverVersion(), comparisons to PG_VERSION_NUM,
and related APIs.  Those most certainly exist now, and trying to supplant
them seems like a giant waste of time.

On the other hand, parsing fields out of version() mechanically has been
deprecated for as long as those other APIs have existed (which is since
8.0 or so).  version() is only meant for human consumption, so I see no
reason it shouldn't just start returning "10.0", "10.1", etc.  If that
breaks anyone's code, well, they should have switched to one of the
easier methods years ago.
        regards, tom lane

On 6/14/16 3:38 PM, Joshua D. Drake wrote:
> On 06/14/2016 12:46 PM, Jim Nasby wrote:
>
>> Any ideas on naming for such a function? version_detail()? I suppose
>> while we're at this we might as well provide the compile details as well.
>
> version(detail) or version(verbose)

I don't think that makes as much sense as a different function name, 
since the output is fundamentally different than version().
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

On 6/14/16 3:56 PM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> On 6/14/16 3:01 PM, Robert Haas wrote:
>>> This seems kind of silly, because anybody who is writing code that
>>> might have to run against an existing version of the database won't be
>>> able to use it.  The one thing that absolutely has to be cross-version
>>> is the method of determining which version you're running against.
>
>> We're talking about a function that doesn't currently exist anyway.
>
> Huh?  We're talking about PQserverVersion(), comparisons to PG_VERSION_NUM,
> and related APIs.  Those most certainly exist now, and trying to supplant
> them seems like a giant waste of time.
>
> On the other hand, parsing fields out of version() mechanically has been
> deprecated for as long as those other APIs have existed (which is since
> 8.0 or so).  version() is only meant for human consumption, so I see no
> reason it shouldn't just start returning "10.0", "10.1", etc.  If that
> breaks anyone's code, well, they should have switched to one of the
> easier methods years ago.

The original post was:

>   IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3

and \df *version* on my HEAD doesn't show any other options.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 6/14/16 3:56 PM, Tom Lane wrote:
>>
>> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>>>
>>> On 6/14/16 3:01 PM, Robert Haas wrote:
>>>>
>>>> This seems kind of silly, because anybody who is writing code that
>>>> might have to run against an existing version of the database won't be
>>>> able to use it.  The one thing that absolutely has to be cross-version
>>>> is the method of determining which version you're running against.
>>
>>
>>> We're talking about a function that doesn't currently exist anyway.
>>
>>
>> Huh?  We're talking about PQserverVersion(), comparisons to
>> PG_VERSION_NUM,
>> and related APIs.  Those most certainly exist now, and trying to supplant
>> them seems like a giant waste of time.
>>
>> On the other hand, parsing fields out of version() mechanically has been
>> deprecated for as long as those other APIs have existed (which is since
>> 8.0 or so).  version() is only meant for human consumption, so I see no
>> reason it shouldn't just start returning "10.0", "10.1", etc.  If that
>> breaks anyone's code, well, they should have switched to one of the
>> easier methods years ago.
>
>
> The original post was:
>
>>   IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3
>
> and \df *version* on my HEAD doesn't show any other options.

Right.  It's the only way to handle things on the SQL level well,
that, and pg_settings approaches.  In other words, there is no easier
way.  I think it's pretty reasonable to assume there's a lot more code
interfacing with the database from SQL than from C.

merlin

On Tue, Jun 14, 2016 at 01:38:44PM -0700, Joshua D. Drake wrote:
> On 06/14/2016 12:46 PM, Jim Nasby wrote:
> 
> >Any ideas on naming for such a function? version_detail()? I suppose
> >while we're at this we might as well provide the compile details as well.
> 
> version(detail) or version(verbose)

If we're looking at forward only changes, is it possible to introduce a
JSONB output to it. Then people can rip out whichever component they want
at will.

For example:

{"full": 10.0,"major": 10,"patchlevel": 0
}

and whatever else may be pertinent. I used numeric types above but they
can be strings if that works better.

We have the capability to provide (semi-)structured data. Might be an idea
to make greater use of it.

--  "A search of his car uncovered pornography, a homemade sex aid, women's  stockings and a Jack Russell terrier."   -
http://www.dailytelegraph.com.au/news/wacky/indeed/story-e6frev20-1111118083480

On 15/06/16 02:08, Cat wrote:
> is it possible to introduce a JSONB output to it.

No thanks.
-- 
Vik Fearing                                          +33 6 46 75 15 36
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

On 06/14/2016 05:08 PM, Cat wrote:

> We have the capability to provide (semi-)structured data. Might be an idea
> to make greater use of it.
>

postgres=# SELECT * from 
to_json(row(current_setting('server_version_num'))) as version;


Sincerely,

jD

-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>
>> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby <Jim.Nasby@bluetreble.com>
>> wrote:
>> > On 6/14/16 3:56 PM, Tom Lane wrote:
>> >>
>> >> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> >>>
>> >>> On 6/14/16 3:01 PM, Robert Haas wrote:
>> >>>>
>> >>>> This seems kind of silly, because anybody who is writing code that
>> >>>> might have to run against an existing version of the database won't
>> >>>> be
>> >>>> able to use it.  The one thing that absolutely has to be
>> >>>> cross-version
>> >>>> is the method of determining which version you're running against.
>> >>
>> >>
>> >>> We're talking about a function that doesn't currently exist anyway.
>> >>
>> >>
>> >> Huh?  We're talking about PQserverVersion(), comparisons to
>> >> PG_VERSION_NUM,
>> >> and related APIs.  Those most certainly exist now, and trying to
>> >> supplant
>> >> them seems like a giant waste of time.
>> >>
>> >> On the other hand, parsing fields out of version() mechanically has
>> >> been
>> >> deprecated for as long as those other APIs have existed (which is since
>> >> 8.0 or so).  version() is only meant for human consumption, so I see no
>> >> reason it shouldn't just start returning "10.0", "10.1", etc.  If that
>> >> breaks anyone's code, well, they should have switched to one of the
>> >> easier methods years ago.
>> >
>> >
>> > The original post was:
>> >
>> >>   IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >= 9.3
>> >
>> > and \df *version* on my HEAD doesn't show any other options.
>>
>> Right.  It's the only way to handle things on the SQL level well,
>> that, and pg_settings approaches.  In other words, there is no easier
>> way.  I think it's pretty reasonable to assume there's a lot more code
>> interfacing with the database from SQL than from C.
>
>
> We could stand to be more explicit here.  The docs for version() indicated
> the server_version_num should be used for "machine processing".

whoop! I didn't know about that setting.  I guess it dismantles a lot
of the case for more aggressive action.  That said, maybe it's a good
idea to construct the versioning change so that 10.x releases have a
server_version_num > 9.x releases and leave the other functions alone
(assuming that wasn't already the plan).

> Option E: Give the DBA control.  If they know they have one or more
> mis-behaving applications but it is out their control to patch the code to
> work properly they can change this supposedly human-readable output to
> conform the historical x.y.z format.  This would disabled by default.
> Humans can easily interpret both versions so please save the comment about
> not having GUCs that influence user-visible behavior.  If your argument for
> changing the format outright is "its for human consumption only" then
> apparently this output should not be considered important enough to adhere
> to that rule.  Non-humans depending on its format are subject to our, or the
> DBA's, whims.

Nah -- my argument could be restated as "I wasn't aware of the machine
variant of the version #".  Do you think it's a good idea to have the
machine version number be 100000 for version 10.0?  What would 10.1
be?  100100 or 100001?

merlin

On Wed, Jun 15, 2016 at 8:59 AM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> On Wed, Jun 15, 2016 at 9:38 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>
>> On Tue, Jun 14, 2016 at 5:48 PM, David G. Johnston
>> <david.g.johnston@gmail.com> wrote:
>> > On Tue, Jun 14, 2016 at 5:58 PM, Merlin Moncure <mmoncure@gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Jun 14, 2016 at 4:13 PM, Jim Nasby <Jim.Nasby@bluetreble.com>
>> >> wrote:
>> >> > On 6/14/16 3:56 PM, Tom Lane wrote:
>> >> >>
>> >> >> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
>> >> >>>
>> >> >>> On 6/14/16 3:01 PM, Robert Haas wrote:
>> >> >>>>
>> >> >>>> This seems kind of silly, because anybody who is writing code that
>> >> >>>> might have to run against an existing version of the database
>> >> >>>> won't
>> >> >>>> be
>> >> >>>> able to use it.  The one thing that absolutely has to be
>> >> >>>> cross-version
>> >> >>>> is the method of determining which version you're running against.
>> >> >>
>> >> >>
>> >> >>> We're talking about a function that doesn't currently exist anyway.
>> >> >>
>> >> >>
>> >> >> Huh?  We're talking about PQserverVersion(), comparisons to
>> >> >> PG_VERSION_NUM,
>> >> >> and related APIs.  Those most certainly exist now, and trying to
>> >> >> supplant
>> >> >> them seems like a giant waste of time.
>> >> >>
>> >> >> On the other hand, parsing fields out of version() mechanically has
>> >> >> been
>> >> >> deprecated for as long as those other APIs have existed (which is
>> >> >> since
>> >> >> 8.0 or so).  version() is only meant for human consumption, so I see
>> >> >> no
>> >> >> reason it shouldn't just start returning "10.0", "10.1", etc.  If
>> >> >> that
>> >> >> breaks anyone's code, well, they should have switched to one of the
>> >> >> easier methods years ago.
>> >> >
>> >> >
>> >> > The original post was:
>> >> >
>> >> >>   IF substring(version() FROM $q$([0-9]+\.[0-9]+)$q$)::NUMERIC >=
>> >> >> 9.3
>> >> >
>> >> > and \df *version* on my HEAD doesn't show any other options.
>> >>
>> >> Right.  It's the only way to handle things on the SQL level well,
>> >> that, and pg_settings approaches.  In other words, there is no easier
>> >> way.  I think it's pretty reasonable to assume there's a lot more code
>> >> interfacing with the database from SQL than from C.
>> >
>> >
>> > We could stand to be more explicit here.  The docs for version()
>> > indicated
>> > the server_version_num should be used for "machine processing".
>>
>> whoop! I didn't know about that setting.  I guess it dismantles a lot
>> of the case for more aggressive action.  That said, maybe it's a good
>> idea to construct the versioning change so that 10.x releases have a
>> server_version_num > 9.x releases and leave the other functions alone
>> (assuming that wasn't already the plan).
>>
>> > Option E: Give the DBA control.  If they know they have one or more
>> > mis-behaving applications but it is out their control to patch the code
>> > to
>> > work properly they can change this supposedly human-readable output to
>> > conform the historical x.y.z format.  This would disabled by default.
>> > Humans can easily interpret both versions so please save the comment
>> > about
>> > not having GUCs that influence user-visible behavior.  If your argument
>> > for
>> > changing the format outright is "its for human consumption only" then
>> > apparently this output should not be considered important enough to
>> > adhere
>> > to that rule.  Non-humans depending on its format are subject to our, or
>> > the
>> > DBA's, whims.
>>
>> Nah -- my argument could be restated as "I wasn't aware of the machine
>> variant of the version #".  Do you think it's a good idea to have the
>> machine version number be 100000 for version 10.0?  What would 10.1
>> be?  100100 or 100001?
>
>
> Sleeping on it I too came to the conclusion that the GUC was largely an
> undesirable option.
>
> IIRC the plan is to have the machine version behave as if the middle number
> is present and always zero.  It would be (the?) one place that the
> historical behavior remains visible but it is impossible to have a totally
> clean break.
>
> Tom's comment back on May 14th (different thread) was that we'd basically
> redefine the minor portion to be 4-digits instead of 2.

That makes sense -- I'm good then.  Thanks for engaging

merlin

On 6/15/16 9:04 AM, Merlin Moncure wrote:
>> We could stand to be more explicit here.  The docs for version()
>> >> > indicated
>> >> > the server_version_num should be used for "machine processing".

On a somewhat related note, any objection to adding server_version_num 
to pg_config? It's common to need to know what version you're handling 
in a Makefile, and today that's pretty ugly (especially when something 
is stamped as beta, since it breaks assumptions about numeric).
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461

<p dir="ltr"><br /> On 15 Jun 2016 2:59 pm, "David G. Johnston" <<a
href="mailto:david.g.johnston@gmail.com">david.g.johnston@gmail.com</a>>wrote:<br /> ><br /> > IIRC the plan
isto have the machine version behave as if the middle number is present and always zero.  It would be (the?) one place
thatthe historical behavior remains visible but it is impossible to have a totally clean break.<br /><p dir="ltr">I
haven'tbeen keeping up with hackers, sorry if this has been suggested already but...<p dir="ltr">Why don't we just
*actually*keep the middle digit and *actually* have it always be zero?<p dir="ltr">So we would release 10.0.0 and
10.0.1and the next major release would be 11.0.0.<p dir="ltr">This would have two benefits:<p dir="ltr">1) It
emphasisesthat minor releases continue to be safe minor updates that offer the same stability guarantees. Users would
beless likely to be intimidated by 10.0.1 than they would be 10.1. And it gives users a consistent story they can apply
toany version whether 9.x or 10.0+<p dir="ltr">2) If we ever do release incompatible feature releases on older branches
--or more likely some fork does -- it gives them a natural way to number their release.  

On Fri, Jun 17, 2016 at 1:01 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> On 17 June 2016 at 08:34, Greg Stark <stark@mit.edu> wrote:
>>
>> So we would release 10.0.0 and 10.0.1 and the next major release would be
>> 11.0.0.
>>
>> This would have two benefits:
>>
>> 1) It emphasises that minor releases continue to be safe minor updates
>> that offer the same stability guarantees. Users would be less likely to be
>> intimidated by 10.0.1 than they would be 10.1. And it gives users a
>> consistent story they can apply to any version whether 9.x or 10.0+
>
>
> And matches semver.
>
>>
>> 2) If we ever do release incompatible feature releases on older branches
>> -- or more likely some fork does -- it gives them a natural way to number
>> their release.
>
> Seems unlikely, though.
>
> I thought about raising this, but I think in the end it's replacing one
> confusing and weird versioning scheme for another confusing and weird
> versioning scheme.
>
> It does have the advantage that that compare a two-part major like 090401 vs
> 090402 won't be confused when they compare 100100 and 100200, since it'll be
> 100001 and 100002. So it's more backward-compatible. But ugly.

Ugliness is a highly subjective qualifier.  OTOH, Backwards
compatibility, at least when the checks are properly written :-), is a
very objective benefit.

merlin

Merlin Moncure wrote:

> Ugliness is a highly subjective qualifier.  OTOH, Backwards
> compatibility, at least when the checks are properly written :-), is a
> very objective benefit.

This is the argument that made us kept the PostgreSQL name instead of
renaming back to Postgres.  I'm not a fan of it.

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

On Fri, Jun 17, 2016 at 1:04 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Merlin Moncure wrote:
>
>> Ugliness is a highly subjective qualifier.  OTOH, Backwards
>> compatibility, at least when the checks are properly written :-), is a
>> very objective benefit.
>
> This is the argument that made us kept the PostgreSQL name instead of
> renaming back to Postgres.  I'm not a fan of it.

I, on the other hand, am a big fan of backward-compatibility.

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

On 06/17/2016 10:04 AM, Alvaro Herrera wrote:
> Merlin Moncure wrote:
> 
>> Ugliness is a highly subjective qualifier.  OTOH, Backwards
>> compatibility, at least when the checks are properly written :-), is a
>> very objective benefit.
> 
> This is the argument that made us kept the PostgreSQL name instead of
> renaming back to Postgres.  I'm not a fan of it.
> 

Well ... no.

We kept the PostgreSQL name for three reasons.

Back in 2005, which was the last time we could have reasonably changed
it, nobody had the time/energy to do all of the
search-and-replace-and-contact-every-packager required.  The folks who
were most enthusiastic about the change wanted someone else to do the
work.  Plus, our Japanese community, which was like 40% of our worldwide
community at the time, was opposed to the change.

The third reason is that we have a registered trademark on "PostgreSQL",
but "postgres" is public domain.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

On 06/16/2016 11:01 PM, Craig Ringer wrote:
> 
> I thought about raising this, but I think in the end it's replacing one
> confusing and weird versioning scheme for another confusing and weird
> versioning scheme.
> 
> It does have the advantage that that compare a two-part major like
> 090401 vs 090402 won't be confused when they compare 100100 and 100200,
> since it'll be 100001 and 100002. So it's more backward-compatible. But
> ugly.
> 

Realistically, though, we're more likely to end up with 10.0.1 than
10.1.  I don't think we're anywhere near plumbing the depths of the
stuff which will break because folks are parsing our version numbers
with regexes.  In more major software, this will break nagios
check_postgres.

I'm not happy with it, but I believe that's where we'll end up.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)

On Sat, Jun 18, 2016 at 05:48:30PM -0700, Josh Berkus wrote:
> On 06/16/2016 11:01 PM, Craig Ringer wrote:
> > 
> > I thought about raising this, but I think in the end it's replacing one
> > confusing and weird versioning scheme for another confusing and weird
> > versioning scheme.
> > 
> > It does have the advantage that that compare a two-part major like
> > 090401 vs 090402 won't be confused when they compare 100100 and 100200,
> > since it'll be 100001 and 100002. So it's more backward-compatible. But
> > ugly.
> 
> Realistically, though, we're more likely to end up with 10.0.1 than
> 10.1.  I don't think we're anywhere near plumbing the depths of the
> stuff which will break because folks are parsing our version numbers
> with regexes.  In more major software, this will break nagios
> check_postgres.
> 
> I'm not happy with it, but I believe that's where we'll end up.

Pulling back a bit from this a bit, I am pretty sure that the fix for
the new announced version numbers, so long as our new policy is clear
and won't be changed again for the foreseeable future has the
following characteristics:

- Not a show-stopper, i.e. people will not drop support in their products for PostgreSQL over this.

- A Matter of Programming that really is small.  The difference between the old three-part/six-digit version encoding
andthe new two-part/four-digit version encoding is stark and simple, as is the code to handle it, even if it's regex.
Bythe time we get to PostgreSQL 100.0, the first starship will already be back, and the 9.x PostgreSQLs will be in
olderto people using them then that the Zuse Z1 https://en.wikipedia.org/wiki/Konrad_Zuse is to us now.
 

Just my $.02.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

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

> On Jun 18, 2016, at 5:48 PM, Josh Berkus <josh@agliodbs.com> wrote:
> 
> On 06/16/2016 11:01 PM, Craig Ringer wrote:
>> 
>> I thought about raising this, but I think in the end it's replacing one
>> confusing and weird versioning scheme for another confusing and weird
>> versioning scheme.
>> 
>> It does have the advantage that that compare a two-part major like
>> 090401 vs 090402 won't be confused when they compare 100100 and 100200,
>> since it'll be 100001 and 100002. So it's more backward-compatible. But
>> ugly.
>> 
> 
> Realistically, though, we're more likely to end up with 10.0.1 than
> 10.1.  I don't think we're anywhere near plumbing the depths of the
> stuff which will break because folks are parsing our version numbers
> with regexes.  In more major software, this will break nagios
> check_postgres.

Having a 3 part versioning scheme where the middle portion is always
zero makes the least sense to me of any of the proposals.  If we're going
to have the pain and hurting of moving to a 2 part versioning scheme,
and breaking nagios and what not, then lets just get on with it.  If we're
going to keep all three parts, can we please use my proposal earlier in
this thread where A.B.C are allocated for:

C++:  bug fixes only
B++:  new features added, but still backward compatible with prior version
A++:  new features added, not backward compatible, pg_upgrade required

If every new feature release ends up requiring pg_upgrade, then B will
always be zero, which is no worse than your proposal.  But at least users can
refer to part B to learn something useful, namely whether they will need to
run pg_upgrade as part of upgrading their existing cluster.

This has the advantage that new minor features, like adding a new guc, can
be released sooner than the next major release, but does not have to be
released in disguise as if it were a bug fix.

This is not a plea for keeping the three part versioning system.  It's just 
a plea not to have a 2 part versioning system masquerading as a three
part versioning system, or vice versa.

mark

> On Jun 18, 2016, at 5:48 PM, Josh Berkus <josh@agliodbs.com> wrote:
>
> On 06/16/2016 11:01 PM, Craig Ringer wrote:
>>
>> I thought about raising this, but I think in the end it's replacing one
>> confusing and weird versioning scheme for another confusing and weird
>> versioning scheme.
>>
>> It does have the advantage that that compare a two-part major like
>> 090401 vs 090402 won't be confused when they compare 100100 and 100200,
>> since it'll be 100001 and 100002. So it's more backward-compatible. But
>> ugly.
>>
>
> Realistically, though, we're more likely to end up with 10.0.1 than
> 10.1.  I don't think we're anywhere near plumbing the depths of the
> stuff which will break because folks are parsing our version numbers
> with regexes.  In more major software, this will break nagios
> check_postgres.

Having a 3 part versioning scheme where the middle portion is always
zero makes the least sense to me of any of the proposals.  If we're going
to have the pain and hurting of moving to a 2 part versioning scheme,
and breaking nagios and what not, then lets just get on with it.  If we're
going to keep all three parts, can we please use my proposal earlier in
this thread where A.B.C are allocated for:

C++:  bug fixes only
B++:  new features added, but still backward compatible with prior version
A++:  new features added, not backward compatible, pg_upgrade required

If every new feature release ends up requiring pg_upgrade, then B will
always be zero, which is no worse than your proposal.  But at least users can
refer to part B to learn something useful, namely whether they will need to
run pg_upgrade as part of upgrading their existing cluster.

This has the advantage that new minor features, like adding a new guc, can
be released sooner than the next major release, but does not have to be
released in disguise as if it were a bug fix.

This is not a plea for keeping the three part versioning system.  It's just
a plea not to have a 2 part versioning system masquerading as a three
part versioning system, or vice versa.

>
> In practical effect that is exactly what your proposal does.  You just feel better because you defined when B is
allowedto change even though it never should happen based upon our project policy.  And any rare exception can
justifiablybe called a bug fix because, face it, it would only happen if someone reports a bug. 

Why are you refusing to acknowledge the difference between features that require a pg_upgrade and features that don't?

> On Jun 20, 2016, at 8:53 AM, Mark Dilger <hornschnorter@gmail.com> wrote:
>
>
> This is not a plea for keeping the three part versioning system.  It's just
> a plea not to have a 2 part versioning system masquerading as a three
> part versioning system, or vice versa.

To clarify my concern, I never want to have to write code like this:
CASE WHEN pg_version eq '11.1' OR pg_version eq '11.0.1' THEN foo()       WHEN pg_version eq '11.2' OR pg_version eq
'11.0.2'THEN bar()    .... 
or
if (0 == strcmp(pg_version_string, "11.1") || 0 == strcmp(pg_version_string, "11.0.1"))    foo();else if (0 ==
strcmp(pg_version_string,"11.2") || 0 == strcmp(pg_version_string, "11.0.2"))    bar(); 

either in sql, perl, c, java, or anywhere else.  As soon as you have two different
formats for the version string, you get into this hell.  Yeah, ok, you may have
a sql level function for this, but I'm thinking about applications somewhat removed
from a direct connection to the database, where you can't be sure which format
you'll be handed.


mark

On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>> In practical effect that is exactly what your proposal does.  You just feel better because you defined when B is
allowedto change even though it never should happen based upon our project policy.  And any rare exception can
justifiablybe called a bug fix because, face it, it would only happen if someone reports a bug. 
>
> Why are you refusing to acknowledge the difference between features that require a pg_upgrade and features that
don't?

The amount of additional committer work that would be created by
making that distinction would be large.  Currently, we're on an annual
release cycle.  Every commit that's not a bug fix gets committed to
exactly one branch: master.  Inevitably, there are multiple changes
per cycle - dozens, probably - that change initial catalog contents
and would therefore require pg_upgrade.

Suppose we switched to a semi-annual release cycle where every other
release required a pg_upgrade, so once per year same as now, and the
other ones did not.  The only way to do that would be to have two
active development branches, one of which accepts only changes that
don't bump catversion or xlog_page_magic and the other of which
accepts changes of all sorts.  Every patch that qualifies for the
no-pg-upgrade-required branch would have to be committed twice,
resolving conflicts as necessary.

Also, over time, the number of supported branches would approximately
double.  With a five year support window, it's currently about six.
If you had another set of semi-major releases in between the main set
of releases, you'd end up with 11 or 12 active branches, which would
make back-patching significantly more burdensome than currently.

Now maybe you have some other idea in mind, but I don't quite
understand what it is.  It's not likely to ever happen that we go
through a whole 12 month release cycle and then get to the end of it
and say "huh, I guess we never bumped catversion or xlog_page_magic".
If that ever does happen, it's probably a sign that nobody is doing
any meaningful feature development any more.

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

> On Jun 20, 2016, at 9:43 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Jun 20, 2016 at 12:26 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>>> In practical effect that is exactly what your proposal does.  You just feel better because you defined when B is
allowedto change even though it never should happen based upon our project policy.  And any rare exception can
justifiablybe called a bug fix because, face it, it would only happen if someone reports a bug. 
>>
>> Why are you refusing to acknowledge the difference between features that require a pg_upgrade and features that
don't?
>
> The amount of additional committer work that would be created by
> making that distinction would be large.  Currently, we're on an annual
> release cycle.  Every commit that's not a bug fix gets committed to
> exactly one branch: master.  Inevitably, there are multiple changes
> per cycle - dozens, probably - that change initial catalog contents
> and would therefore require pg_upgrade.
>
> Suppose we switched to a semi-annual release cycle where every other
> release required a pg_upgrade, so once per year same as now, and the
> other ones did not.  The only way to do that would be to have two
> active development branches, one of which accepts only changes that
> don't bump catversion or xlog_page_magic and the other of which
> accepts changes of all sorts.  Every patch that qualifies for the
> no-pg-upgrade-required branch would have to be committed twice,
> resolving conflicts as necessary.
>
> Also, over time, the number of supported branches would approximately
> double.  With a five year support window, it's currently about six.
> If you had another set of semi-major releases in between the main set
> of releases, you'd end up with 11 or 12 active branches, which would
> make back-patching significantly more burdensome than currently.
>
> Now maybe you have some other idea in mind, but I don't quite
> understand what it is.

I do, indeed, and here it is:

When considering whether to *back port* a change, we typically do so
on the basis that bug fixes are back ported, features are not.  In my
proposed versioning scheme, you could back port any feature that is
compatible with the old version, and bump the middle number to alert
users that you've not just back ported a bug fix, but a feature.  Any new
features that are not compatible don't get back ported.

If you fix a bug on master during development, you can back port that
as well.  But instead of bumping the middle number, you bump the last
number.

Somebody running a version that is three major versions back could
still get the advantage of new features, so long as those new features
are not incompatible.  It's frequently not nearly so easy to run pg_upgrade
as it is to run rpm -U.  You get downtime either way, but the elapsed
time of that downtime is orders of magnitude different.

Someone else running that same version from three major versions ago
can take a more conservative policy, and only upgrade bug fixes, and
forego the back ported features.

You still have one major version release per year.  At that time, you can
also release back-port versions of prior major versions.

> On Jun 20, 2016, at 9:38 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Mon, Jun 20, 2016 at 12:28 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>
> > On Jun 20, 2016, at 8:53 AM, Mark Dilger <hornschnorter@gmail.com> wrote:
> >
> >
> > This is not a plea for keeping the three part versioning system.  It's just
> > a plea not to have a 2 part versioning system masquerading as a three
> > part versioning system, or vice versa.
>
> To clarify my concern, I never want to have to write code like this:
>
>         CASE WHEN pg_version eq '11.1' OR pg_version eq '11.0.1' THEN foo()
>                    WHEN pg_version eq '11.2' OR pg_version eq '11.0.2' THEN bar()
>                 ....
> or
>
>         if (0 == strcmp(pg_version_string, "11.1") || 0 == strcmp(pg_version_string, "11.0.1"))
>                 foo();
>         else if (0 == strcmp(pg_version_string, "11.2") || 0 == strcmp(pg_version_string, "11.0.2"))
>                 bar();
>
> either in sql, perl, c, java, or anywhere else.  As soon as you have two different
> formats for the version string, you get into this hell.  Yeah, ok, you may have
> a sql level function for this, but I'm thinking about applications somewhat removed
> from a direct connection to the database, where you can't be sure which format
> you'll be handed.
>
> Now you argue for keeping the middle number on pure compatibility grounds.​..

I am not arguing for that.  I'm arguing against having two different versions of the
same thing.  If you go with a two part versioning scheme that is sometimes written as a
three part versioning scheme, you make every bit of code that deals with it from now on
have to deal with both possible versions in order to be robust.

My preference is to have a three part versioning scheme where all three parts have
different purposes.  But since the community seems to have no interest in that, and
have largely (if not universally) rejected that idea, I'm falling back to merely arguing
that if we're going to have a two part versioning system, we should do that everywhere,
and if we can't do that everywhere, then we should do that nowhere.

You appear to be arguing that we should have a versioning scheme that is sometimes
two parts, and sometimes three parts, but when three parts, always make the middle
number zero.  The part of that which bothers me most is not the "always zero" part.   It's
the "sometimes two parts, sometimes three parts" part.

mark

Mark Dilger wrote:

> When considering whether to *back port* a change, we typically do so
> on the basis that bug fixes are back ported, features are not.  In my
> proposed versioning scheme, you could back port any feature that is
> compatible with the old version, and bump the middle number to alert
> users that you've not just back ported a bug fix, but a feature.  Any new
> features that are not compatible don't get back ported.

So instead of having about 5 branches to maintain, we will end up with
5N branches, because we will still have to support the initial .0
branches of each major, plus .1, .2 ... of each major branch?

Granted, we could have major releases not every year but perhaps every 2
or 3 years; non-catversion-bumping patches would still be released
quicker than that, in middle-number-increasing releases.  But like
Robert, I don't think that the number of features we could add this way
would be numerous enough to support this idea in the long run.

I think this increases the load on committers many times.  Count me out.

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

> On Jun 20, 2016, at 11:06 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
>
> On 06/20/2016 10:45 AM, Mark Dilger wrote:
>
>>> Now maybe you have some other idea in mind, but I don't quite
>>> understand what it is.
>>
>> I do, indeed, and here it is:
>>
>> When considering whether to *back port* a change, we typically do so
>> on the basis that bug fixes are back ported, features are not.  In my
>> proposed versioning scheme, you could back port any feature that is
>> compatible with the old version, and bump the middle number to alert
>> users that you've not just back ported a bug fix, but a feature.  Any new
>> features that are not compatible don't get back ported.
>>
>> If you fix a bug on master during development, you can back port that
>> as well.  But instead of bumping the middle number, you bump the last
>> number.
>>
>> Somebody running a version that is three major versions back could
>> still get the advantage of new features, so long as those new features
>> are not incompatible.  It's frequently not nearly so easy to run pg_upgrade
>> as it is to run rpm -U.  You get downtime either way, but the elapsed
>> time of that downtime is orders of magnitude different.
>>
>> Someone else running that same version from three major versions ago
>> can take a more conservative policy, and only upgrade bug fixes, and
>> forego the back ported features.
>>
>> You still have one major version release per year.  At that time, you can
>> also release back-port versions of prior major versions.
>
> OFFLIST:
>
> You are fighting a losing if noble battle.

I think all my emails on this subject have been seriously misunderstood.
Perhaps the problem is that I don't understand some critical issue.  Can
you please help me understand this part:

It seems like people want releases, starting with 10.0, to be named things
like 10.0, 10.1, 10.2,..., but for the purposes of communicating with programs
like nagios refer to them as 10.0.0, 10.0.1, 10.0.2

Is that right?

That's the part that really annoys me, and I keep trying to argue for not doing
that, and people keep replying to other parts of my messages rather than
replying to the core part of what I am saying.

Why would any sensible person want a release to sometimes be called
"10.4", but the exact same release sometimes referred to as "10.0.4"?
This is just going to confuse average software users, as they would never
expect that 10.4 and 10.0.4 are the same thing.

Have I misunderstood what is being proposed?

The only reason I talk about using the middle number for this other purpose
is to forestall people assuming that they can elide the middle number of a
three number system, such that it gets elided sometimes but not other times.
I was quite clear in my email this morning that I'm not arguing for a three
number system.  I'm perfectly ok with a two number system.  I just don't want
a "let's confuse everybody by making each and every release have two
different names" system.

mark

> On Jun 20, 2016, at 11:30 AM, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Mon, Jun 20, 2016 at 2:14 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>
> > On Jun 20, 2016, at 11:06 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
> >
> > On 06/20/2016 10:45 AM, Mark Dilger wrote:
> >
> >>> Now maybe you have some other idea in mind, but I don't quite
> >>> understand what it is.
> >>
> >> I do, indeed, and here it is:
> >>
> >> When considering whether to *back port* a change, we typically do so
> >> on the basis that bug fixes are back ported, features are not.  In my
> >> proposed versioning scheme, you could back port any feature that is
> >> compatible with the old version, and bump the middle number to alert
> >> users that you've not just back ported a bug fix, but a feature.  Any new
> >> features that are not compatible don't get back ported.
> >>
> >> If you fix a bug on master during development, you can back port that
> >> as well.  But instead of bumping the middle number, you bump the last
> >> number.
> >>
> >> Somebody running a version that is three major versions back could
> >> still get the advantage of new features, so long as those new features
> >> are not incompatible.  It's frequently not nearly so easy to run pg_upgrade
> >> as it is to run rpm -U.  You get downtime either way, but the elapsed
> >> time of that downtime is orders of magnitude different.
> >>
> >> Someone else running that same version from three major versions ago
> >> can take a more conservative policy, and only upgrade bug fixes, and
> >> forego the back ported features.
> >>
> >> You still have one major version release per year.  At that time, you can
> >> also release back-port versions of prior major versions.
> >
> > OFFLIST:
> >
> > You are fighting a losing if noble battle.
>
> I think all my emails on this subject have been seriously misunderstood.
> Perhaps the problem is that I don't understand some critical issue.  Can
> you please help me understand this part:
>
> It seems like people want releases, starting with 10.0, to be named things
> like 10.0, 10.1, 10.2,..., but for the purposes of communicating with programs
> like nagios refer to them as 10.0.0, 10.0.1, 10.0.2
>
> Is that right?
>
> That's the part that really annoys me, and I keep trying to argue for not doing
> that, and people keep replying to other parts of my messages rather than
> replying to the core part of what I am saying.
>
> Why would any sensible person want a release to sometimes be called
> "10.4", but the exact same release sometimes referred to as "10.0.4"?
> This is just going to confuse average software users, as they would never
> expect that 10.4 and 10.0.4 are the same thing.
>
> Have I misunderstood what is being proposed?
>
> ​The software is only ever going to report 10.0.4 OR 10.4.  The area of concern is that people are going to get
annoyedat saying: "that was fixed in 10.0.4​" and so mailing lists and other forums where people write the numbers
insteadof a computer are going to be littered with: "that was fixed in 10.4". 
>
> So now human speak and machine speak are disjointed.
>
> ​The machine form output for that release is going to be 100004 regardless of the decision to make the human form
10.4or 10.0.4 
>
> Do you have a problem with the human form and machine forms of the version number being different in this respect?  I
don't- for me the decision of a choice for the human form is not influenced by the fact the machine form has 6 digits
(withleading zeros which the human form elides...). 

I don't have a problem with it if humans always use a two part number.  I don't read
the number 100004 as being three parts, nor as being two parts, so it doesn't matter.
What got me to respond this morning was Josh's comment:

"Realistically, though, we're more likely to end up with 10.0.1 than 10.1."

He didn't say "100001 than 10.1", he said "10.0.1 than 10.1", which showed that we
already have a confusion waiting to happen.

Now, you can try to avoid the confusion by saying that we'll always use all three
digits of the number rather than just two, or always use two digits rather than three.
But how do you enforce that?  If in some sense the middle number exists, but is
always zero, then some people will mention it and some won't, with the result that
10.0.x and 10.x will be used by different people at different times to refer to the same
release.

The problem that Tom and others mentioned upthread (rather a while ago) is that
up until now, we've had three digits in the version numbers, but the first two numbers
really just mean one thing, "major", and the last number means "minor".  IIUC, he
wanted to stop using two separate digits where clearly just one would suffice.  Hence
the proposal to go to things like 10.0, 10.1.  But others chimed in saying that we need
to keep it three parts for compatibility reasons, so how about we just have the middle
number always be zero.  My response to that is what I've just said.  You can't do that
without creating ambiguity in future version numbers, because of how people use
language.  If you want to avoid the ambiguity and confusion going forward, all the
numbers in the scheme must have meaning and not be mere placeholders.  I gave a
suggestion about what the middle number *could* mean, which I don't deny is what
I'd like best, but it's just a suggestion to avoid the confusion inherent in people eliding
the middle number sometimes but not other times.

> On Jun 20, 2016, at 1:00 PM, David G. Johnston <david.g.johnston@gmail.com> wrote:
>
> On Mon, Jun 20, 2016 at 3:08 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
>
> > Do you have a problem with the human form and machine forms of the version number being different in this respect?
Idon't - for me the decision of a choice for the human form is not influenced by the fact the machine form has 6 digits
(withleading zeros which the human form elides...). 
>
> I don't have a problem with it if humans always use a two part number.  I don't read
> the number 100004 as being three parts, nor as being two parts, so it doesn't matter.
> What got me to respond this morning was Josh's comment:
>
> "Realistically, though, we're more likely to end up with 10.0.1 than 10.1."
>
> He didn't say "100001 than 10.1", he said "10.0.1 than 10.1", which showed that we
> already have a confusion waiting to happen.
>
> Now, you can try to avoid the confusion by saying that we'll always use all three
> digits of the number rather than just two, or always use two digits rather than three.
> But how do you enforce that?
>
> ​You do realize he was referring to machine generated output here?

No I don't, nor will anyone who finds that via a google search.  That's my point.
You core hackers feel perfectly comfortable with that because you understand
what you are talking about.  Hardly anybody else will.

As you suggest, that's my $0.02, and I'm moving on.

mark

On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> 10.x is the desired output.

10.x is the output that some people desire.  A significant number of
people, including me, would prefer to stick with the current
three-part versioning scheme, possibly with some change to the
algorithm for bumping the first digit (e.g. every 5 years like
clockwork).

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

Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> <david.g.johnston@gmail.com> wrote:
>> 10.x is the desired output.

> 10.x is the output that some people desire.  A significant number of
> people, including me, would prefer to stick with the current
> three-part versioning scheme, possibly with some change to the
> algorithm for bumping the first digit (e.g. every 5 years like
> clockwork).

If we were going to do it like that, I would argue for "every ten years
like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
Robert, you already made your case for that approach and nobody else
cared for it.  Either there's a meaningful difference between the first
and second parts of the number, or there is not.  If there is not, why
have separate parts?  It can only cause confusion ... as this whole
thread, and its many many predecessors, amply illustrate.
        regards, tom lane

Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> > <david.g.johnston@gmail.com> wrote:
> >> 10.x is the desired output.
> 
> > 10.x is the output that some people desire.  A significant number of
> > people, including me, would prefer to stick with the current
> > three-part versioning scheme, possibly with some change to the
> > algorithm for bumping the first digit (e.g. every 5 years like
> > clockwork).
> 
> If we were going to do it like that, I would argue for "every ten years
> like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
> Robert, you already made your case for that approach and nobody else
> cared for it.

I voted for this approach initially too, and I think it has merit --
notably, that it would stop this discussion.  It was said that moving
to two-part numbers would stop all discussion, but it seems to have had
exactly the opposite effect.

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

On 06/20/2016 01:41 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
>>> <david.g.johnston@gmail.com> wrote:

>> If we were going to do it like that, I would argue for "every ten years
>> like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
>> Robert, you already made your case for that approach and nobody else
>> cared for it.
>
> I voted for this approach initially too, and I think it has merit --
> notably, that it would stop this discussion.  It was said that moving
> to two-part numbers would stop all discussion, but it seems to have had
> exactly the opposite effect.
>

Or we could adopt the very reasonable and practical policy of:

The current versioning scheme isn't broke, so we aren't going to fix it.

Put that in the FAQ and wave at it like we do with hints ala Oracle.

It is obvious from this thread alone that there is really no consensus.

Sincerely,

JD

-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

On Mon, Jun 20, 2016 at 4:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
>> <david.g.johnston@gmail.com> wrote:
>>> 10.x is the desired output.
>
>> 10.x is the output that some people desire.  A significant number of
>> people, including me, would prefer to stick with the current
>> three-part versioning scheme, possibly with some change to the
>> algorithm for bumping the first digit (e.g. every 5 years like
>> clockwork).
>
> If we were going to do it like that, I would argue for "every ten years
> like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
> Robert, you already made your case for that approach and nobody else
> cared for it.  Either there's a meaningful difference between the first
> and second parts of the number, or there is not.  If there is not, why
> have separate parts?  It can only cause confusion ... as this whole
> thread, and its many many predecessors, amply illustrate.

That's not how I remember it.  At the Ottawa developer meeting, there
were more votes for changing to a two-part versioning scheme than
there were for retaining a three-part versioning scheme, but my
recollection not overwhelmingly so.  I'm pretty sure it was less than
a 2/3 majority in favor of changing.

Furthermore, essentially everyone in the room, including people who
wanted to stick with a three-part scheme, was in favor of the next
version's first component being 10.  I do not recall there being a
strong consensus among the people who wanted the next version to be
10.0.0 on how to decide when to go to 11.0.0, though.  Various
proposals were offered and most of them got no more than one vote.

But saying that nobody other than me thought we should stick with a
three-part scheme is revisionist history.

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

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> If we were going to do it like that, I would argue for "every ten years
>> like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
>> Robert, you already made your case for that approach and nobody else
>> cared for it.

> I voted for this approach initially too, and I think it has merit --
> notably, that it would stop this discussion.  It was said that moving
> to two-part numbers would stop all discussion, but it seems to have had
> exactly the opposite effect.

No, the argument for it was that we'd no longer have to have the annual
discussions about "is it 10.0 yet?".  There was no claim that getting
there would be uncontroversial, only that things would be quieter once
we did get there.

Considering that same long-term viewpoint, I'm not very happy about the
idea of "let's reserve the middle digit for compatible feature backports",
because the minute we set up a numbering system like that, everybody and
his brother will be arguing for making a branch on which to backport their
favorite more-or-less-compatible new feature.  You as well as others
pointed out that we don't have the manpower to actually support any such
thing ... so let's not open the door to it.

If we do arrive at a consensus that going to simply "10.0, 10.1, etc"
would be too much change, then I'd be in favor of adopting the
every-ten-year rule instead, in hopes that we can at least shut down
future "is it 10.0 yet" threads more quickly.  But that really does
nothing at all to fix the confusion so often shown by outsiders about
the significance of our version numbers.
        regards, tom lane

On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> Or we could adopt the very reasonable and practical policy of:
>
> The current versioning scheme isn't broke, so we aren't going to fix it.

Yeah, no kidding.  We had a perfectly good consensus to keep this at
9.6 on pgsql-advocacy, and then later we had a revised consensus to
retitle it to 10.0, but as soon as the discussion came over to
pgsql-hackers nothing would do but that we relitigate the whole thing
ignoring the previous discussion because it wasn't on pgsql-hackers.
Why -hackers is the right place to decide on the marketing version
number rather than -advocacy went unexplained, of course.  Now we have
a new consensus, at least the third if not the fourth or fifth, about
what to do on this topic, and since Tom likes this outcome better he'd
like to stop discussion right here.  A two-part version numbering
scheme may or may not be for the best, but the idea that we're making
that decision in any principled way, or that the consensus on this new
system is any more valid than any of the previous consensus, doesn't
ring true to me.  The idea that this discussion is not fixing any real
problem, though -- that rings true.

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

On Mon, Jun 20, 2016 at 4:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> No, the argument for it was that we'd no longer have to have the annual
> discussions about "is it 10.0 yet?".

WHAT annual argument?  Did anyone even argue that any 9.x release
prior to 9.6 deserved to be called 10.0?  Maybe somebody suggested
that for 9.2 and it generated, like, four emails?  I certainly don't
remember any discussion that remotely approached the amount of time
we've spent litigating both the version number and the version
numbering scheme in the last few months.

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

On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> Or we could adopt the very reasonable and practical policy of:
>>
>> The current versioning scheme isn't broke, so we aren't going to fix it.
>
> The idea that this discussion is not fixing any real
> problem, though -- that rings true.

sure -- it's my fault for starting the conversation back up.  I was
wondering about supporting older version checks, but only because I
was unaware of the 'machine' variant of the version check
(server_version_num), which properly supports numerical ordering for
historical versions.  If there's anything to do here, maybe we ought
to document that server_version_num should be used for checking
version a little more strongly.  Judging by google searching, this is
as not widely known as it should be.

merlin

On 06/20/2016 02:14 PM, Merlin Moncure wrote:
> On Mon, Jun 20, 2016 at 4:08 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>>> Or we could adopt the very reasonable and practical policy of:
>>>
>>> The current versioning scheme isn't broke, so we aren't going to fix it.
>>
>> The idea that this discussion is not fixing any real
>> problem, though -- that rings true.
>
> sure -- it's my fault for starting the conversation back up.  I was
> wondering about supporting older version checks, but only because I
> was unaware of the 'machine' variant of the version check
> (server_version_num), which properly supports numerical ordering for
> historical versions.  If there's anything to do here, maybe we ought
> to document that server_version_num should be used for checking
> version a little more strongly.  Judging by google searching, this is
> as not widely known as it should be.

I certainly had no idea it even existed until you displayed the query. I 
have always used version() but then, I am not a -hacker.

Sincerely,

JD

>
> merlin
>


-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.

On Mon, Jun 20, 2016 at 5:36 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
>> Yeah, no kidding.  We had a perfectly good consensus to keep this at
>> 9.6 on pgsql-advocacy, and then later we had a revised consensus to
>> retitle it to 10.0,
>
> If -advocacy had changed their mind before beta1 was tagged this may have
> played out a bit differently...maybe.  In any case 9.6 was a foregone
> conclusion given -advocacy's timeline and because of its independence from
> -hackers (Tom, the tagger, specifically).

One thing to keep in mind is that I did not realize there was any
urgency to make the decision before beta1, because Tom had previous
made reference to renumbering this version to 10.0 *over the summer*
depending on how awesome we then thought parallel query was.  I
assumed that he would not have made this comment if he had an
objection to renumbering the release after beta1.  Surely he didn't
think we were going to do beta1 in the fall.  It was only after beta1
had been released that anyone said post-beta1 was too late.  Had that
been brought up earlier, the discussion might have gone differently,
too.

Also, it is not the case that because Tom applies the tag, he also
gets veto power over the version numbering scheme.  That's not how
decision-making in this community works.

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

On Mon, May 16, 2016 at 10:16:48AM -0400, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> > On 5/16/16 9:53 AM, Greg Stark wrote:
> >> I thought the idea was that Berkeley tossed an source tree over the
> >> wall with no version number and then the first five releases were
> >> Postgres95 0.x, Postgres95 1.0, Postgres95 1.0.1, Postgres95 1.0.2,
> >> Postgres95 1.0.9. Then the idea was that PostgreSQL 6.0 was the sixth
> >> major release counting those as the first five releases.
> 
> > The last release out of Berkeley was 4.2.
> 
> Correct --- I have a copy of that tarball.
> 
> > Then Postgres95 was "5", and then PostgreSQL started at 6.
> 
> I wasn't actually around at the time, but our commit history starts
> with this:
> 
> Author: Marc G. Fournier <scrappy@hub.org>
> Branch: master Release: REL6_1 [d31084e9d] 1996-07-09 06:22:35 +0000
> 
>     Postgres95 1.01 Distribution - Virgin Sources
> 
> The first mention of 6.anything is here:
> 
> Author: Bruce Momjian <bruce@momjian.us>
> Branch: master Release: REL6_1 [a2b7f6297] 1996-12-28 02:01:58 +0000
> 
>     Updated changes for 6.0.
> 
> I see no references in the commit history to 5.anything, but there
> are some references like this:

The sole reason we jumped from Postgres 1.09 to 6.0 was that in Postgres
1.0.X, $PGDATA/PG_VERSION contained '5', meaning when Berkeley went from
University Postgres 4.2 to Postgres95 1.0, they didn't reset PG_VERSION.

We really had no way of going to Postgres 2.0 unless we were prepared to
have data/PG_VERSION never match the major version number.

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

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

On Mon, Jun 20, 2016 at 05:11:17PM -0400, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > No, the argument for it was that we'd no longer have to have the annual
> > discussions about "is it 10.0 yet?".
> 
> WHAT annual argument?  Did anyone even argue that any 9.x release
> prior to 9.6 deserved to be called 10.0?  Maybe somebody suggested
> that for 9.2 and it generated, like, four emails?  I certainly don't
> remember any discussion that remotely approached the amount of time
> we've spent litigating both the version number and the version
> numbering scheme in the last few months.

I do think Robert is 100% accurate on this.  Personally, I have never
understood the reduce arguments reason, and the jump to 8.0 and 9.0 were
done in a positive way that I think provided value to our community.

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

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

On 20/06/2016 22:41, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
>>> <david.g.johnston@gmail.com> wrote:
>>>> 10.x is the desired output.
>>
>>> 10.x is the output that some people desire.  A significant number of
>>> people, including me, would prefer to stick with the current
>>> three-part versioning scheme, possibly with some change to the
>>> algorithm for bumping the first digit (e.g. every 5 years like
>>> clockwork).
>>
>> If we were going to do it like that, I would argue for "every ten years
>> like clockwork", e.g. 10.0.x is next after 9.9.x.  But in point of fact,
>> Robert, you already made your case for that approach and nobody else
>> cared for it.
> 
> I voted for this approach initially too, and I think it has merit --
> notably, that it would stop this discussion.  It was said that moving
> to two-part numbers would stop all discussion, but it seems to have had
> exactly the opposite effect.

If voting is still possible, then I agree: no changes please!
It won't make things easier to have a 10g or a 10.8 to explain, instead
of a 10.0.8... and I'm not sure it'll make things easier to not have the
chance to bump the 2 major parts if it happened to be interesting in the
future like it was for 7.4->8 and 8.4->9 (9 is «new», it's the first
time we go over .4 to bump first digit, but it's also the first time we
have found a way to shorten release cycle)

-- 
-- 
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

On 06/20/2016 10:14 PM, Robert Haas wrote:
> On Mon, Jun 20, 2016 at 4:00 PM, David G. Johnston
> <david.g.johnston@gmail.com> wrote:
>> 10.x is the desired output.
> 10.x is the output that some people desire.

(explicitly skipped up-thread to add this -- please forgive my jumping in)

Since we are still (as a community) debating this, I felt the need to 
add yet another possibility ...    (/me dons some asbestos underwear)

next version:
100100 [server_version] will be  (gasp!)  10g R1 (for marketing people) 
or simply 10.1.0 for the rest of the world.    Next update would be 1001001, a.k.a. 10g R1 u1
    i.e. we would skip 10.0 alltogether, preserving everybody's sanity 
in the process.


IMV,  10g R1 uX should plainly be a different *major* release than 10g 
R2 uY    and hence requiring a proper "migration" (i.e. pg_upgrade)    ...or at least that's what several multi-billion
softwarecompanies 
 
have taught most everybody to believe :$


> A significant number of
> people, including me, would prefer to stick with the current
> three-part versioning scheme, possibly with some change to the
> algorithm for bumping the first digit (e.g. every 5 years like
> clockwork).
That's another story....  Either 5 (for historical reasons) or 10 year 
(sounds good) ... or whenever it makes sense! (such as when a multi-modal, hybrid 
row+column, vectored, MPP, super-duper-distributed, automagically 
self-scaling or the like release is ready)


Thanks,
    / J.L.

On 21/06/16 03:53, Mark Dilger wrote:
>> On Jun 18, 2016, at 5:48 PM, Josh Berkus <josh@agliodbs.com> wrote:
>>
>> On 06/16/2016 11:01 PM, Craig Ringer wrote:
>>> I thought about raising this, but I think in the end it's replacing one
>>> confusing and weird versioning scheme for another confusing and weird
>>> versioning scheme.
>>>
>>> It does have the advantage that that compare a two-part major like
>>> 090401 vs 090402 won't be confused when they compare 100100 and 100200,
>>> since it'll be 100001 and 100002. So it's more backward-compatible. But
>>> ugly.
>>>
>> Realistically, though, we're more likely to end up with 10.0.1 than
>> 10.1.  I don't think we're anywhere near plumbing the depths of the
>> stuff which will break because folks are parsing our version numbers
>> with regexes.  In more major software, this will break nagios
>> check_postgres.
> Having a 3 part versioning scheme where the middle portion is always
> zero makes the least sense to me of any of the proposals.  If we're going
> to have the pain and hurting of moving to a 2 part versioning scheme,
> and breaking nagios and what not, then lets just get on with it.  If we're
> going to keep all three parts, can we please use my proposal earlier in
> this thread where A.B.C are allocated for:
>
> C++:  bug fixes only
> B++:  new features added, but still backward compatible with prior version
> A++:  new features added, not backward compatible, pg_upgrade required
>
> If every new feature release ends up requiring pg_upgrade, then B will
> always be zero, which is no worse than your proposal.  But at least users can
> refer to part B to learn something useful, namely whether they will need to
> run pg_upgrade as part of upgrading their existing cluster.
>
> This has the advantage that new minor features, like adding a new guc, can
> be released sooner than the next major release, but does not have to be
> released in disguise as if it were a bug fix.
>
> This is not a plea for keeping the three part versioning system.  It's just
> a plea not to have a 2 part versioning system masquerading as a three
> part versioning system, or vice versa.
>
> mark
>
>
I agree with this!

I hate the rampant inflation associated with numbering schemes like 
FireFox - the numbers of no meaning at all, other than something 
non-trivial has been changed, with no indication at all about how 
non-trivial!



Cheers,
Gavin

Gavin Flower wrote:

> I hate the rampant inflation associated with numbering schemes like FireFox
> - the numbers of no meaning at all, other than something non-trivial has
> been changed, with no indication at all about how non-trivial!

I thought this horse had already been beaten to death -- apparently not?

It was stated somewhere in these threads that the problem with the
Firefox scheme is that they release new versions every six weeks, so
naturally there is enormous version number inflation.  In our case we
would still release new versions once a year, so by 2026 (ten years from
now) we would be releasing Postgres 19 while Firefox will be in version 133.

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