10.0

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 +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

På fredag 13. mai 2016 kl. 17:05:23, skrev Robert Haas <robertmhaas@gmail.com
<mailto: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
 
Thanks.
 
-- Andreas Joseph Krogh

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Friday, May 13, 2016, Bruce Momjian <bruce@momjian.us> wrote:

On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote:

* Dave Page (dpage@pgadmin.org <javascript:;>) 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". ;-)

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

Stephen

On Friday, May 13, 2016, Dave Page <dpage@pgadmin.org> wrote:

On Fri, May 13, 2016 at 5:08 PM, Bruce Momjian <bruce@momjian.us
<javascript:;>> wrote:

On Fri, May 13, 2016 at 12:05:34PM -0400, Stephen Frost wrote:

* Dave Page (dpage@pgadmin.org <javascript:;>) 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? :-)

We'll just say you have to be using a special collation with 9.5.0 to get
the right sort order.. ;)

/me hides from Peter

Thanks!

Stephen

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

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)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

På fredag 13. mai 2016 kl. 18:22:00, skrev Magnus Hagander <magnus@hagander.net
<mailto:magnus@hagander.net>>:
On Fri, May 13, 2016 at 5:42 PM, Andreas Joseph Krogh <andreas@visena.com
<mailto:andreas@visena.com>> wrote: På fredag 13. mai 2016 kl. 17:05:23, skrev
Robert Haas <robertmhaas@gmail.com <mailto: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".

 
I don't think anyone expects all of them for a 10.0 release:-) I just listed
some stuff which would, IMHO, validate a 10.0 release, some combined with
others, others alone (like MMR).
 
-- Andreas Joseph Krogh

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers