Thread: 9.6 -> 10.0

Hi,

I've been ranting about this on Twitter for a while, and now blogged about it:

http://people.planetpostgresql.org/devrim/index.php?/archives/89-9.6,-or-10.0.html

There are major changes in 9.6 (some of them are listed in the blog post), and
I think they are good enough to call this 10.0.

A counter argument might be waiting for pglogical for inclusion, but I think
the current changes are enough to warrant a .0 release.

What do you think?

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 22 Mar 2016, at 14:07, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
> Hi,
>
> I've been ranting about this on Twitter for a while, and now blogged about it:
>
> http://people.planetpostgresql.org/devrim/index.php?/archives/89-9.6,-or-10.0.html
>
> There are major changes in 9.6 (some of them are listed in the blog post), and
> I think they are good enough to call this 10.0.
>
> A counter argument might be waiting for pglogical for inclusion, but I think
> the current changes are enough to warrant a .0 release.
>
> What do you think?

Heh Heh Heh, I was thinking about this last night too.

For a 10.0 release, that's a very major jump from the 9.x series.

The question is... are we there yet?

Is so, then yay :)... if not though, what is the bar we need to reach?

  eg Transparent multi-master replication built-in to core? ;)

Regards and best wishes,

Justin Clift

On Tue, Mar 22, 2016 at 04:07:42PM +0200, Devrim Gunduz wrote:
>
> Hi,
>
> I've been ranting about this on Twitter for a while, and now blogged about it:
>
> http://people.planetpostgresql.org/devrim/index.php?/archives/89-9.6,-or-10.0.html
>
> There are major changes in 9.6 (some of them are listed in the blog post), and
> I think they are good enough to call this 10.0.
>
> A counter argument might be waiting for pglogical for inclusion, but I think
> the current changes are enough to warrant a .0 release.
>
> What do you think?

I think a big question is whether we want to save 10.0 for some
incompatibility changes, though we didn't do that for 8.0 or 9.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. +
+ Roman grave inscription                             +

Hi Justin,

On Tue, 2016-03-22 at 14:10 +0000, Justin Clift wrote:
>
> For a 10.0 release, that's a very major jump from the 9.x series.
>
> The question is... are we there yet?
>
> Is so, then yay :)... if not though, what is the bar we need to reach?
>
>   eg Transparent multi-master replication built-in to core? ;)

We always have 11.0. :-)

Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

Hi,

> On Mar 22, 2016, at 10:07 AM, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
>
>
> Hi,
>
> I've been ranting about this on Twitter for a while, and now blogged about it:
>
> http://people.planetpostgresql.org/devrim/index.php?/archives/89-9.6,-or-10.0.html
>
> There are major changes in 9.6 (some of them are listed in the blog post), and
> I think they are good enough to call this 10.0.
>
> A counter argument might be waiting for pglogical for inclusion, but I think
> the current changes are enough to warrant a .0 release.
>
> What do you think?


Perhaps we can use the “survey” feature on .org to get some quantitative feedback and see what the temperature is of
theoverall community for the upgrade.  I would be happy to put it together and help promote it. 

Ultimately I think everyone is going to have their own opinion about what constitutes us to switch to the 10.x series.
Itmay be best to leave it up to -core to decide if we should roll over the first number.  This is not to squelch any
discussion,rather it’s to keep some perspective on the outcome :-) 

Thanks!

Jonathan

On 22 Mar 2016, at 14:21, Devrim GÜNDÜZ <devrim@gunduz.org> wrote:
> Hi Justin,
>
> On Tue, 2016-03-22 at 14:10 +0000, Justin Clift wrote:
>>
>> For a 10.0 release, that's a very major jump from the 9.x series.
>>
>> The question is... are we there yet?
>>
>> Is so, then yay :)... if not though, what is the bar we need to reach?
>>
>>   eg Transparent multi-master replication built-in to core? ;)
>
> We always have 11.0. :-)

"For this release, we turned the volume up to 11!" :)

+ Justin

On 03/22/2016 07:11 AM, Bruce Momjian wrote:
> On Tue, Mar 22, 2016 at 04:07:42PM +0200, Devrim Gunduz wrote:
>>
>> Hi,
>>
>> I've been ranting about this on Twitter for a while, and now blogged about it:
>>
>> http://people.planetpostgresql.org/devrim/index.php?/archives/89-9.6,-or-10.0.html
>>
>> There are major changes in 9.6 (some of them are listed in the blog post), and
>> I think they are good enough to call this 10.0.
>>
>> A counter argument might be waiting for pglogical for inclusion, but I think
>> the current changes are enough to warrant a .0 release.
>>
>> What do you think?
>
> I think a big question is whether we want to save 10.0 for some
> incompatibility changes, though we didn't do that for 8.0 or 9.0.

AFAIK, there are no such incompatibilities proposed for any major
features.  So it might be time to stop holding out for those.

If you compare 9.0 with 9.6, it's a pretty radically different database.
 Here's all of the things which 9.6 will/might have which 9.0 did not:

* FDWs
* Parallel Query
* Built-in logical replication
* JSON support
* Background workers
* No more SysV mem
* ALTER SYSTEM
... etc.

Particularly, we've knocked out at least two of the "big five" technical
challenges, Parallel Query and upgrade without downtime.  Given that, it
really seems like we're on version 10 now.

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

On 03/22/2016 09:10 AM, Magnus Hagander wrote:
> While having parallelism is awesome, it's only going to affect a
> (arguably small or big depending on your viewpoint) subset of users.
> It's going to be massive for those users, but it's not going to be
> useful for anywhere near as many users as streaming replication+hot
> standby+pg_upgrade in 9.0, or pitr+windows in 8.0. And yes, the vacuum
> freeze thing is also going to be great - for a small subset of users
> (yes, those users are in a lot of pain now).
>
>
> I had a discussion with Marko T just a couple of weeks back, and the
> conclusion then was that at the time, 9.6 had almost nothing that would
> even make the cut for a press release. We now have these two features,
> which are great features, but I'm not sure it's enough for such a big
> symbolical bump.

Wait, pglogical didn't make it?

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

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


> I had a discussion with Marko T just a couple of weeks back, and the
> conclusion then was that at the time, 9.6 had almost nothing that would
> even make the cut for a press release. We now have these two features,
> which are great features, but I'm not sure it's enough for such a big
> symbolical bump.

Postgres 10: we finally fixed our stupid name!

:)

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

iEYEAREDAAYFAlbxdm0ACgkQvJuQZxSWSsjOEwCgggx+w2A5N5sy3P+2EnLyP559
e00An0VWQH9UpxvWd41ttGJx/e1DXzUV
=nWtM
-----END PGP SIGNATURE-----

On 03/22/2016 09:15 AM, Josh berkus wrote:

> Wait, pglogical didn't make it?

As far as I know, it didn't and from what I have read of it (and watched
with people trying to use it), it is certainly not done.

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, Mar 22, 2016 at 12:10 PM, Magnus Hagander <magnus@hagander.net> wrote:
> Someone (can't remember who) suggested a good time is to do it when we can
> allow actual zero-or-close-to-zero-downtime upgrades.
>
> While having parallelism is awesome, it's only going to affect a (arguably
> small or big depending on your viewpoint) subset of users. It's going to be
> massive for those users, but it's not going to be useful for anywhere near
> as many users as streaming replication+hot standby+pg_upgrade in 9.0, or
> pitr+windows in 8.0. And yes, the vacuum freeze thing is also going to be
> great - for a small subset of users (yes, those users are in a lot of pain
> now).
>
> I had a discussion with Marko T just a couple of weeks back, and the
> conclusion then was that at the time, 9.6 had almost nothing that would even
> make the cut for a press release. We now have these two features, which are
> great features, but I'm not sure it's enough for such a big symbolical bump.

This release includes, so far, three things that I think are pretty
significant.  One is parallel query, now including target list, join,
and aggregate pushdown.  The second is the freeze map, which is surely
the largest vacuum improvement since 8.4.  The third is the
enhancements to postgres_fdw, which can now push down joins, sorts,
and DML.  There are still some other very good features under
consideration, like Tomas Vondra's multivariate statistics work.  I
think that saying we have nothing that would make the cut for the
press release is awfully pessimistic, considering that in 9.4 I got a
major feature credit for adding an API that could be used only by
writing C code.  Compared to that, all of these features are pretty
fantastic.

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

On Tue, Mar 22, 2016 at 08:54:55AM -0700, Josh Berkus wrote:
> >> A counter argument might be waiting for pglogical for inclusion, but I think
> >> the current changes are enough to warrant a .0 release.
> >>
> >> What do you think?
> >
> > I think a big question is whether we want to save 10.0 for some
> > incompatibility changes, though we didn't do that for 8.0 or 9.0.
>
> AFAIK, there are no such incompatibilities proposed for any major
> features.  So it might be time to stop holding out for those.

I think there was talk of breaking pg_upgrade duringr an increase in the
first digit, but as you stated, there isn't any technical demand for
that.

--
  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. +
+ Roman grave inscription                             +

On 03/22/2016 10:11 AM, Bruce Momjian wrote:

>
> I think there was talk of breaking pg_upgrade duringr an increase in the
> first digit, but as you stated, there isn't any technical demand for
> that.
>

I don't see a reason for the 10.x jump. If PgLogical and/or BDR had been
ready, then absolutely. Although the parallel query is certainly of
importance, I don't know if it is any more important than the
scalability fixes we got in 9.5.x.

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 Mar 22, 2016 5:53 PM, "Robert Haas" <robertmhaas@gmail.com> wrote:
>
> On Tue, Mar 22, 2016 at 12:10 PM, Magnus Hagander <magnus@hagander.net> wrote:
> > Someone (can't remember who) suggested a good time is to do it when we can
> > allow actual zero-or-close-to-zero-downtime upgrades.
> >
> > While having parallelism is awesome, it's only going to affect a (arguably
> > small or big depending on your viewpoint) subset of users. It's going to be
> > massive for those users, but it's not going to be useful for anywhere near
> > as many users as streaming replication+hot standby+pg_upgrade in 9.0, or
> > pitr+windows in 8.0. And yes, the vacuum freeze thing is also going to be
> > great - for a small subset of users (yes, those users are in a lot of pain
> > now).
> >
> > I had a discussion with Marko T just a couple of weeks back, and the
> > conclusion then was that at the time, 9.6 had almost nothing that would even
> > make the cut for a press release. We now have these two features, which are
> > great features, but I'm not sure it's enough for such a big symbolical bump.
>
> This release includes, so far, three things that I think are pretty
> significant.  One is parallel query, now including target list, join,
> and aggregate pushdown.  The second is the freeze map, which is surely
> the largest vacuum improvement since 8.4.  The third is the
> enhancements to postgres_fdw, which can now push down joins, sorts,
> and DML.  There are still some other very good features under
> consideration, like Tomas Vondra's multivariate statistics work.  I
> think that saying we have nothing that would make the cut for the
> press release is awfully pessimistic, considering that in 9.4 I got a
> major feature credit for adding an API that could be used only by
> writing C code.  Compared to that, all of these features are pretty
> fantastic.

Most of that was committed *after* our discussion. It's definitely a very solid release now. (and I agree that was a somewhat weird feature credit in 9.4,but hey, we also got most of our json publicity for the one in 9.2, not the really useful one in 9.4. Our track record with these things isn't really the best..).

Is it enough for 10.0? I'm still doubtful. If more of the stuff that's in the queue now gets committed, there's definitely a chance I'll change my mind. But we shouldn't decide on version numbers based on what might happen, only on what actually happens.

/Magnus

On Tue, Mar 22, 2016 at 06:18:16PM +0100, Magnus Hagander wrote:
> > This release includes, so far, three things that I think are pretty
> > significant.  One is parallel query, now including target list, join,
> > and aggregate pushdown.  The second is the freeze map, which is surely
> > the largest vacuum improvement since 8.4.  The third is the
> > enhancements to postgres_fdw, which can now push down joins, sorts,
> > and DML.  There are still some other very good features under
> > consideration, like Tomas Vondra's multivariate statistics work.  I

FYI, I am super-excited by Tomas Vondra's multivariate statistics work. :-)

--
  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. +
+ Roman grave inscription                             +

On Tue, Mar 22, 2016 at 1:18 PM, Magnus Hagander <magnus@hagander.net> wrote:
> Most of that was committed *after* our discussion. It's definitely a very
> solid release now. (and I agree that was a somewhat weird feature credit in
> 9.4,but hey, we also got most of our json publicity for the one in 9.2, not
> the really useful one in 9.4. Our track record with these things isn't
> really the best..).

Yes, it's been a busy couple of weeks.  But I'd also point out, if you
look at the last few releases, that the background worker major
feature credit wasn't incredibly exceptional.  For example, 9.4 also
gave a major feature credit to "Allow materialized views to be
refreshed without blocking concurrent reads", but I think few people
would argue that materialized views as they exist in PG today are a
first-class feature - for that, we need *incremental* refresh.  We got
"Reduce lock strength for some ALTER TABLE commands", but only
rarely-used commands that aren't really the major problem with ALTER
TABLE.  The really big thing in 9.4, technologically speaking, was
"Add support for logical decoding of WAL data, to allow database
changes to be streamed out in a customizable format".  But that was
another C API.  A bloody good one, to be sure, but a C API all the
same.  In contrast, the big stuff we have in 9.6 is all stuff you can
really use.

> Is it enough for 10.0? I'm still doubtful. If more of the stuff that's in
> the queue now gets committed, there's definitely a chance I'll change my
> mind. But we shouldn't decide on version numbers based on what might happen,
> only on what actually happens.

Sure, let's see what else we get.  Are you working on committing any
of that stuff in the queue?  What that's still in the queue are you
particularly excited about?

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

On 03/22/2016 10:18 AM, Magnus Hagander wrote:.
>
> Most of that was committed *after* our discussion. It's definitely a
> very solid release now. (and I agree that was a somewhat weird feature
> credit in 9.4,but hey, we also got most of our json publicity for the
> one in 9.2, not the really useful one in 9.4. Our track record with
> these things isn't really the best..).

It's important to remember that PR strategy and engineering truth have
only a passing acquaintance.  While we don't want to promote vaporware,
we do sometimes soft-pedal our own features to our project's detriment.
In the current atomosphere of VC-funded hype, we'd do a bit better to
trumpet our accomplishements early and often.

Not that that has any effect on 10.0 vs. 9.6.

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

On Tue, Mar 22, 2016 at 10:41 AM, Josh berkus <josh@agliodbs.com> wrote:
> It's important to remember that PR strategy and engineering truth have
> only a passing acquaintance.  While we don't want to promote vaporware,
> we do sometimes soft-pedal our own features to our project's detriment.
> In the current atomosphere of VC-funded hype, we'd do a bit better to
> trumpet our accomplishements early and often.

I see what you mean.

The question must be asked: What feature *would* meet that "major
version bump" standard? If it's not extensive parallelism, then I
don't know what else it could be.

--
Regards,
Peter Geoghegan

On 03/22/2016 10:52 AM, Peter Geoghegan wrote:
> On Tue, Mar 22, 2016 at 10:41 AM, Josh berkus <josh@agliodbs.com> wrote:
>> It's important to remember that PR strategy and engineering truth have
>> only a passing acquaintance.  While we don't want to promote vaporware,
>> we do sometimes soft-pedal our own features to our project's detriment.
>> In the current atomosphere of VC-funded hype, we'd do a bit better to
>> trumpet our accomplishements early and often.
>
> I see what you mean.
>
> The question must be asked: What feature *would* meet that "major
> version bump" standard? If it's not extensive parallelism, then I
> don't know what else it could be.

BDR or PgLogical or Native Partitioning or Federation/Sharding.

The parallelism is AWESOME!

It is also something that I think a lot of users do not consider a major
feature as much as a major, "it is about time" (although partitioning
probably falls in that too).

That is not to take away from Robert's work which is AWESOME.

Yes I can say AWESOME a lot.

It is just that the feature, is essentially, "We are faster, yet again".

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 03/22/2016 10:52 AM, Peter Geoghegan wrote:
> On Tue, Mar 22, 2016 at 10:41 AM, Josh berkus <josh@agliodbs.com> wrote:
>> It's important to remember that PR strategy and engineering truth have
>> only a passing acquaintance.  While we don't want to promote vaporware,
>> we do sometimes soft-pedal our own features to our project's detriment.
>> In the current atomosphere of VC-funded hype, we'd do a bit better to
>> trumpet our accomplishements early and often.
>
> I see what you mean.
>
> The question must be asked: What feature *would* meet that "major
> version bump" standard? If it's not extensive parallelism, then I
> don't know what else it could be.

Well, if we had pglogical AND parallel, I would be pushing hard for
10.0.  As it is, I was going to wait to see what else gets in.

As it is, we have parallel and we have all of the BDR dependancies
merged in, no?  That still seems like a new era for PostgreSQL; I think
we can expect the next few releases to be all about (a) parallelizing
more things and (b) building out clustering stuff.

One thing we don't much talk about is that we hit an inflection point
somewhere in the 9.X series, as demonstrated by CitusDB: it is now as
easy to build out your "Postgres Fork" by using our APIs and hooks as it
is by forking the project.  That's going to make a big difference for us
in the long run, possibly bigger than any individual feature.

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

Peter Geoghegan wrote:

> The question must be asked: What feature *would* meet that "major
> version bump" standard? If it's not extensive parallelism, then I
> don't know what else it could be.

Somebody mentioned partitioning.

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

On 22 March 2016 at 18:01, Joshua D. Drake <jd@commandprompt.com> wrote:
> On 03/22/2016 10:52 AM, Peter Geoghegan wrote:
>>
>> On Tue, Mar 22, 2016 at 10:41 AM, Josh berkus <josh@agliodbs.com> wrote:
>>>
>>> It's important to remember that PR strategy and engineering truth have
>>> only a passing acquaintance.  While we don't want to promote vaporware,
>>> we do sometimes soft-pedal our own features to our project's detriment.
>>> In the current atomosphere of VC-funded hype, we'd do a bit better to
>>> trumpet our accomplishements early and often.
>>
>>
>> I see what you mean.
>>
>> The question must be asked: What feature *would* meet that "major
>> version bump" standard? If it's not extensive parallelism, then I
>> don't know what else it could be.
>
>
> BDR or PgLogical or Native Partitioning or Federation/Sharding.

The partitioning work is nice, but isn't that really just a way of
making partitioning easier?  We already have partitioning.  We never
had parallelism.

It could be argued we also have sharding with foreign table inheritance.

So really, it's BDR that's being argued as the reason for the big
jump, but then, what percentage of users will that be a big thing for?

I don't think any alternatives that anyone has put forward yet
constitutes compelling arguments for a major version bump.

Thom

On Tue, Mar 22, 2016 at 11:33 AM, Thom Brown <thom@linux.com> wrote:
> I don't think any alternatives that anyone has put forward yet
> constitutes compelling arguments for a major version bump.

My point is that we have to bump the major version at some point.
There isn't going to be another Hot Standby + Streaming replication
sea-change in one release.

--
Regards,
Peter Geoghegan

On 03/22/2016 11:33 AM, Thom Brown wrote:

>> BDR or PgLogical or Native Partitioning or Federation/Sharding.
>
> The partitioning work is nice, but isn't that really just a way of
> making partitioning easier?

No, we don't at least not completely. Two simple, required problems we
don't solve:

Primary Keys
Foreign Keys

>  We already have partitioning.  We never
> had parallelism.

But we should of, it is an architectural limitation we are fixing one
that is largely transparent and invisible to every user. Partitioning is
a user/dba space thing that people will see and will actively use.

>
> It could be argued we also have sharding with foreign table inheritance.
>
> So really, it's BDR that's being argued as the reason for the big
> jump, but then, what percentage of users will that be a big thing for?

# of users is irrelevant (There are far more people NOT using JSON than
there are that do. Guess what people talk about?)

# of people talking about it is.

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, Mar 22, 2016 at 2:33 PM, Thom Brown <thom@linux.com> wrote:
> So really, it's BDR that's being argued as the reason for the big
> jump, but then, what percentage of users will that be a big thing for?

If I had to guess: a pretty big percentage, but it didn't get into 9.5
and it looks like it won't get into 9.6, either.  And I'm not sure we
can just say, hey, well, you know, we'll wait until it does.  We don't
know when or if that is going to happen.  I don't think we want to be
releasing 9.10 or 9.12.  Besides, when it does happen, that release
may not having anything else that exciting in it.  I wouldn't like to
dump on logical replication as a feature - it's a great feature, and
we should have it in core.  Maybe I should have worked harder to get
it committed this cycle, but:

1. I thought Andres or Alvaro or Simon would probably do that, and
2. I had a few other features I was busy with which are also pretty good.

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

On 03/22/2016 11:38 AM, Peter Geoghegan wrote:
> On Tue, Mar 22, 2016 at 11:33 AM, Thom Brown <thom@linux.com> wrote:
>> I don't think any alternatives that anyone has put forward yet
>> constitutes compelling arguments for a major version bump.
>
> My point is that we have to bump the major version at some point.
> There isn't going to be another Hot Standby + Streaming replication
> sea-change in one release.

I would argue that BDR or PgLogical is very much that.


--
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, Mar 22, 2016 at 4:45 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> It would make more sense to declare a release 10.0 in advance at the May dev
> meeting, then work to put in a whole load of incompatibilities all into one
> release. i.e. a planned compatibility break, which is what everybody will
> think we have done if we declare 10.0. They will then be surprised if that
> all happens in 10.1 or some other time.
> My list of incompatibilities would be
> * SQL compliant identifiers
> * Remove RULEs
> * Change recovery.conf
> * Change block headers
> * Retire template0, template1
> * Optimise FSM
> * Add heap metapage
> * Alter tuple headers
> et al

A lot of these strike me as things that have never been discussed and
that there's no consensus to actually do.  But I also don't think that
they'd require a 10.0 if we did do them. Why would we need a 10.0 to
add a metapage to the heap?  Presumably that would be done in a fully
backward-compatible way, so no user impact.

In general, I'm pretty skeptical of the idea of having a release where
we just change a lot of things incompatibly.  That seems like a recipe
for having a lot of users who stay with the last release prior to the
break for a very long time, or even give up on PostgreSQL altogether.
It could even lead to a fork.  We've never done that before - bumps to
the first version number have always been driven by features, not
incompatibilities - and I think projects that have done it have often
not been too pleased with the results.

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

On Tue, Mar 22, 2016 at 5:35 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> All of the above have been discussed as some point in last decade as I
> recall, no doubt many more I forget. I made a point to add the one you had
> suggested, as well as suggestions from Heikki and others.

OK, but I never suggested that needed a 10.0.  And I don't think any
of them do, except maybe if we change the storage format in a
backward-incompatible way.  Which I think would be a bad plan.

> I didn't claim there was consensus to do any of them, but I'm pretty sure
> they need to be mentioned first to find out which ones would be agreeable.

Certainly, no argument there.

> "It could even lead to a fork". As could anything, I guess. Who would lead
> this fork, and why?

Well, sure, anything could lead to a fork.  But specifically, if we
decide to make backward-incompatible changes and people don't think
it's worth upgrading, that could create problems for the project.  A
fork is the worst case, where somebody decides to go maintain the code
from before those changes.  More likely, people would end up just
staying on 9.99999 for a really, really long time.

My point is: I don't endorse the idea that we should EVER have a
release that involves a major incompatibilities.  And smaller
incompatibilities can be introduced gradually over time, same as we've
always done.  I think it's right to think that we should stamp 10.0
when we have a really good release with great features, same as we did
with 9.0 and 8.0 and 7.0 (IIUC).

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

On 2016-03-22 7:07 AM, Devrim GÜNDÜZ wrote:
> I've been ranting about this on Twitter for a while, and now blogged about it:
>
> http://people.planetpostgresql.org/devrim/index.php?/archives/89-9.6,-or-10.0.html
>
> There are major changes in 9.6 (some of them are listed in the blog post), and
> I think they are good enough to call this 10.0.
>
> A counter argument might be waiting for pglogical for inclusion, but I think
> the current changes are enough to warrant a .0 release.
>
> What do you think?

I have several thoughts about this.

1. I think we should default to keeping the 9.6 version as being perfectly
acceptable as a default position.

2. I think a major milestone would be when one can use BDR on an UNPATCHED core
Postgres server, so BDR is then easily installable as an extension or complement
with standard Postgres.

Per
http://blog.2ndquadrant.com/when-are-we-going-to-contribute-bdr-to-postgresql/ I
have been seeing major chunks of this BDR-derived stuff being added to core in
9.3, 9.4, 9.5 and there being relatively little left.

While not necessarily a cause for a 10.0, I think it would be a dis-service to
relabel 9.6 as 10.0 unless it satisfied the UNPATCHED requirement.

This is assuming that getting there is an "almost done" thing, sure to be in 9.7
if not 9.6, though it seemed 9.6 was the likely thing.

If I understand things right then the pglogical is the main outstanding piece?

3. A major milestone to warrant a .0 release is core support for alternate
primary query languages than SQL, which I think was discussed as something
desirable in -hackers a year back or so.  At the same time, this sort of thing
if done still looks like a few years out and a 10.0 should not be held for it.
But then maybe including such would warrant an 11.0 release.

4. I don't think its a bad idea to release a 10.0 simply to say we've got a good
accumulated batch of features since 9.0 by now, even if the actual delta from
say 9.5 isn't as impressive looking; in that sense the 10.0 is more like saying
we have something more polished.

-- Darren Duncan

Le Tue, 22 Mar 2016 22:41:35 +0300,
Oleg Bartunov <obartunov@gmail.com> a écrit :

> On Tue, Mar 22, 2016 at 8:52 PM, Peter Geoghegan <
> peter.geoghegan86@gmail.com> wrote:
>
> > On Tue, Mar 22, 2016 at 10:41 AM, Josh berkus <josh@agliodbs.com> wrote:
> > > It's important to remember that PR strategy and engineering truth have
> > > only a passing acquaintance.  While we don't want to promote vaporware,
> > > we do sometimes soft-pedal our own features to our project's detriment.
> > > In the current atomosphere of VC-funded hype, we'd do a bit better to
> > > trumpet our accomplishements early and often.
> >
> > I see what you mean.
> >
> > The question must be asked: What feature *would* meet that "major
> > version bump" standard? If it's not extensive parallelism, then I
> > don't know what else it could be.
> >
>
> Built-in HA Cluster. Hope  to discuss it on PGCon.  I thought about release
> 10 in the context of cluster.

I would say "better HA cluster". Good HA is really challenging and rely on many
moving parts or outside technologies from the architecture. I don't know what
you might mean by "Built-in".

Funny, I was joking with a colleague about that today: «Really, the features
that deserves the 10.0 version are GUC-ing the recovery.conf and supports
online-demote»

Regards,
--
Jehan-Guillaume de Rorthais
Dalibo

On 22.03.2016 16:54, Josh berkus wrote:
> On 03/22/2016 07:11 AM, Bruce Momjian wrote:
>> On Tue, Mar 22, 2016 at 04:07:42PM +0200, Devrim Gunduz wrote:
>>>
>>> Hi,
>>>
>>> I've been ranting about this on Twitter for a while, and now blogged about it:
>>>
>>> http://people.planetpostgresql.org/devrim/index.php?/archives/89-9.6,-or-10.0.html
>>>
>>> There are major changes in 9.6 (some of them are listed in the blog post), and
>>> I think they are good enough to call this 10.0.
>>>
>>> A counter argument might be waiting for pglogical for inclusion, but I think
>>> the current changes are enough to warrant a .0 release.
>>>
>>> What do you think?
>>
>> I think a big question is whether we want to save 10.0 for some
>> incompatibility changes, though we didn't do that for 8.0 or 9.0.
>
> AFAIK, there are no such incompatibilities proposed for any major
> features.  So it might be time to stop holding out for those.
>
> If you compare 9.0 with 9.6, it's a pretty radically different database.
>   Here's all of the things which 9.6 will/might have which 9.0 did not:
>
> * FDWs
> * Parallel Query
> * Built-in logical replication
> * JSON support
> * Background workers
> * No more SysV mem
> * ALTER SYSTEM
> ... etc.
>
> Particularly, we've knocked out at least two of the "big five" technical
> challenges, Parallel Query and upgrade without downtime.  Given that, it
> really seems like we're on version 10 now.

What are the other 3?

Greetings,
Torsten

On Tue, Apr 5, 2016 at 10:25 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 22 March 2016 at 20:45, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> While having parallelism is awesome, it's only going to affect a
>>> (arguably small or big depending on your viewpoint) subset of users. It's
>>> going to be massive for those users, but it's not going to be useful for
>>> anywhere near as many users as streaming replication+hot standby+pg_upgrade
>>> in 9.0, or pitr+windows in 8.0. And yes, the vacuum freeze thing is also
>>> going to be great - for a small subset of users (yes, those users are in a
>>> lot of pain now).
>>
>> We don't yet have full parallel query, we only have parallel scan and
>> parallel aggregation.
>
> My comment here missed the point that parallel hash join is also now
> possible for small hash tables, so we at least have a useful subset of
> functionality across parallel scan/join/agg.

Not sure if this matters to you, but nested loops with an inner index
scan also work.  The thing we don't support in parallel yet is merge
joins.

The reason for that is that, while it's pretty obvious how to
parallelize a hash join or nested loop - just have each process handle
some of the rows - it's really unclear what it means to do a merge
join in parallel.  In fact, you basically can't; it's an inherently
serial algorithm.  My understanding of the literature in this area is
that the trick used by other systems is basically to do a bunch of
small merge joins instead of one big one.  For example, if you have
two compatibly partitioned tables, you can merge join each pair of
partitions instead of merge-joining the appendrels.  Then you get a
bunch of small merge joins that can be scheduled across as many
workers as you have.  Once we have declarative partitioning, this
should be doable.

There's more that can be done: given two tables partitioned
incompatibly, or one partitioned table and one unpartitioned table,
the literature talks about doing an on-the-fly repartitioning of one
of the tables to match the existing partitioning scheme of the other,
after which you again have N separate merge joins that you can
schedule across your pool of workers.  What's not clear to me is
whether trying to get this sort of thing working is the best use of
developer time.  At least in the short term, I think there are other
parallel query limitations more in need of being lifted.

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

On 4/5/16 9:25 AM, Simon Riggs wrote:
> I'm still in favour of a compatibility break, planned in advance and it
> makes most sense to call that 10.0

My view is that's just not an option. You'd be putting a huge burden on
a lot of users that have never had it before, and putting some of our
users in the position of abandoning Postgres altogether (I'm pretty sure
there are still users where having 2 copies of their database just isn't
an option).

(And just so no one thinks I'm some pg_upgrade zealot, I've never
actually used it...)
--
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

On 04/05/2016 06:03 PM, Jim Nasby wrote:
> On 4/5/16 9:25 AM, Simon Riggs wrote:
>> I'm still in favour of a compatibility break, planned in advance and it
>> makes most sense to call that 10.0
>
> My view is that's just not an option. You'd be putting a huge burden on
> a lot of users that have never had it before, and putting some of our
> users in the position of abandoning Postgres altogether (I'm pretty sure
> there are still users where having 2 copies of their database just isn't
> an option).
>
> (And just so no one thinks I'm some pg_upgrade zealot, I've never
> actually used it...)

There will be a compatibility break, it will have to happen. That said,
there are ways to mitigate a good portion of the concerns.

1. Make sure the release before the compatibility break is supported for
longer than usual (say 7 instead of 5 years)

2. Announce the compatibility break AT LEAST 2 versions before it happens

3. Make sure we have some kind of utility that can deal with it, this
might be something that rewrites the pages or perhaps we rely on logical
replication?

And really, if we are going to lose users for doing what's best for the
users... they aren't users. They are bus riders in the night, looking
for a destination they will never find, with a heart heavy with remorse
because they refuse to commit to anything.

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 2016-04-05 6:21 PM, Joshua D. Drake wrote:
> There will be a compatibility break, it will have to happen. That said, there
> are ways to mitigate a good portion of the concerns.
>
> 1. Make sure the release before the compatibility break is supported for longer
> than usual (say 7 instead of 5 years)
>
> 2. Announce the compatibility break AT LEAST 2 versions before it happens
>
> 3. Make sure we have some kind of utility that can deal with it, this might be
> something that rewrites the pages or perhaps we rely on logical replication?

I think you should explain better what you mean by point 2.

You only REALLY need to announce a compatibility break at the time of the break,
eg, this new version is incompatible in these ways, and if you're not ready to
compensate for it, stick with the prior version, which will be supported for
longer time.

The only reason I see to declare a break so far in advance is if in concert you
are making related changes to the prior versions, for example that they would
produce warnings (which can be disabled) on any action that will later break
with a subsequent upgrade, or if the breaks are of the kind that you can support
the new way and old way at once, so people can convert to something that will
work post-break while still being on the pre-break version; or otherwise there's
still the warnings.

The other reason for pre-announcement is so the Postgres devs have a long time
to think about the break in an are-you-sure manner, and announcing its
possibility with a release is forcing more scrutiny, where feedback can possibly
change its course.

Otherwise, what did you have in mind?

-- Darren Duncan

On Tue, Apr 5, 2016 at 9:21 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> And really, if we are going to lose users for doing what's best for the
> users... they aren't users. They are bus riders in the night, looking for a
> destination they will never find, with a heart heavy with remorse because
> they refuse to commit to anything.

Oh, come on.  Are you seriously going to blame users for not being
zealous enough to endure any and all compatibility breaks we might
inflict on them?  That seems like blaming the victim.  People are
going to pick the tools that are the easiest to use, and
backward-compatibility is part of that.  Ease of use is not a feature
of which we have so much that we can afford to squander it.

For the most part, we've been very successful in *not* breaking
backward compatibility and I think we owe a good part of our success
to that.  When we've deviated from that principle (ahem, 8.3) it's
been very painful, and I can't imagine why we'd want to go through
that again, unless we just have a masochistic streak.

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

On 04/05/2016 06:43 PM, Robert Haas wrote:
> On Tue, Apr 5, 2016 at 9:21 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> And really, if we are going to lose users for doing what's best for the
>> users... they aren't users. They are bus riders in the night, looking for a
>> destination they will never find, with a heart heavy with remorse because
>> they refuse to commit to anything.
>
> Oh, come on.  Are you seriously going to blame users for not being
> zealous enough to endure any and all compatibility breaks we might
> inflict on them?  That seems like blaming the victim.  People are
> going to pick the tools that are the easiest to use, and
> backward-compatibility is part of that.  Ease of use is not a feature
> of which we have so much that we can afford to squander it.

Perhaps my humour was a little abstract.

I was actually trying to give our users credit. Our users know that we
wouldn't break compatibility unless we absolutely saw a reason for it
and that we planned for it. Lastly, that we would show them the respect
they deserve by communicating with them in a way that gives them time to
plan for something like that.

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 04/05/2016 06:42 PM, Darren Duncan wrote:
> On 2016-04-05 6:21 PM, Joshua D. Drake wrote:
>> There will be a compatibility break, it will have to happen. That
>> said, there
>> are ways to mitigate a good portion of the concerns.
>>
>> 1. Make sure the release before the compatibility break is supported
>> for longer
>> than usual (say 7 instead of 5 years)
>>
>> 2. Announce the compatibility break AT LEAST 2 versions before it happens
>>
>> 3. Make sure we have some kind of utility that can deal with it, this
>> might be
>> something that rewrites the pages or perhaps we rely on logical
>> replication?
>
> I think you should explain better what you mean by point 2.

I was thinking that if we have a set of planned changes that we know are
going to break compatibility, we announce that the changes will be
coming in Z, which should be after X and Y releases.

This allows production users (especially those that run for a minimum of
5 years on a release) to plan for the eventual pain.

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 4/5/16 9:01 PM, Joshua D. Drake wrote:
> I was actually trying to give our users credit. Our users know that we
> wouldn't break compatibility unless we absolutely saw a reason for it
> and that we planned for it. Lastly, that we would show them the respect
> they deserve by communicating with them in a way that gives them time to
> plan for something like that.

FWIW, the users I was thinking of in particular are those folks running
databases that are so large it's impractical for them to have more than
one copy. Maybe by the time 9.6 goes EOL YottaByte drives will be so
cheap that it doesn't matter, but I don't think we should count on that.

Also, I disagree with your assertion that we must eventually have a
compatibility break. Anything is possible in software, if you're willing
to expend the effort on it. ISTR that even just a few years before Bruce
wrote pg_upgrade people were saying that wasn't possible either.

So the first question needs to be not "When?" but "Should we?" Before
that can be answered we need a list of TODO items that would break
pg_upgrade as it exists today. Then some thought can be put into what it
would take to support an in-place upgrade with those changes. MAYBE it
turns out that it's just too much effort and we do need a break, but
that needs to be a very well justified decision.
--
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

On Wed, Apr 6, 2016 at 4:56 PM, Jim Nasby <jim@nasby.net> wrote:
> So the first question needs to be not "When?" but "Should we?" Before that
> can be answered we need a list of TODO items that would break pg_upgrade as
> it exists today. Then some thought can be put into what it would take to
> support an in-place upgrade with those changes. MAYBE it turns out that it's
> just too much effort and we do need a break, but that needs to be a very
> well justified decision.

Well said.

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

On Tue, Apr 5, 2016 at 6:43 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> For the most part, we've been very successful in *not* breaking
> backward compatibility and I think we owe a good part of our success
> to that.  When we've deviated from that principle (ahem, 8.3) it's
> been very painful, and I can't imagine why we'd want to go through
> that again, unless we just have a masochistic streak.

I agree that we shouldn't go through that again unless we have a very
good reason, which I don't think we do in the case of breaking on-disk
compatibility -- it isn't particularly burdening us. I disagree with
the implication that the 8.3 changes were a bad decision at the time.

--
Regards,
Peter Geoghegan

On 4/6/16 5:30 PM, Simon Riggs wrote:
> Deciding not to have a compatibility break release means that such
> things will remain forever blocked or we slowly increase the amount of
> old code we have to support all the multiple options needed, which will
> affect bug rates and support costs.

I think that's a pretty hand-wavy statement until the problems have been
documented, along with some thought and estimation of potential
compatible work-arounds.

> I don't really mind what we do, as long as we choose that direction via
> a conscious, rational choice.

Absolutely.

I'll try to start a list on the wiki this weekend, unless someone beats
me to it.
--
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

On 4/7/16 1:54 AM, Simon Riggs wrote:
>     I think that's a pretty hand-wavy statement until the problems have
>     been documented, along with some thought and estimation of potential
>     compatible work-arounds.
>
>
> By hand-wavy, you mean not fully worked out? Yes, neither the pros and
> cons have been worked out in detail, so opposing the idea is on the same
> shaky ground. How then to proceed?

Do we even have a list of things we'd like to do that would break
compatibility? I haven't seen one...
--
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

On 9 Apr 2016, at 19:50, Jim Nasby <jim@nasby.net> wrote:
> On 4/7/16 1:54 AM, Simon Riggs wrote:
<snip>
>> By hand-wavy, you mean not fully worked out? Yes, neither the pros and
>> cons have been worked out in detail, so opposing the idea is on the same
>> shaky ground. How then to proceed?
>
> Do we even have a list of things we'd like to do that would break compatibility? I haven't seen one...

Simon's email a few weeks ago is probably a decent starting point:

  http://www.postgresql.org/message-id/CANP8+jLtk1NtaJyXc=hAqX=0k+ku4zfavgVBKfs+_sOr9hepNQ@mail.gmail.com

From that:

  * SQL compliant identifiers
  * Remove RULEs
  * Change recovery.conf
  * Change block headers
  * Retire template0, template1
  * Optimise FSM
  * Add heap metapage
  * Alter tuple headers
  et al

+ Justin

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

On 4/9/16 2:07 PM, Justin Clift wrote:
>> Do we even have a list of things we'd like to do that would break compatibility? I haven't seen one...
> Simon's email a few weeks ago is probably a decent starting point:
>
>    http://www.postgresql.org/message-id/CANP8+jLtk1NtaJyXc=hAqX=0k+ku4zfavgVBKfs+_sOr9hepNQ@mail.gmail.com
>
>  From that:
>
>    * SQL compliant identifiers
>    * Remove RULEs
>    * Change recovery.conf
>    * Change block headers
>    * Retire template0, template1
>    * Optimise FSM
>    * Add heap metapage
>    * Alter tuple headers

I think there needs to be some discussion on a larger list (ie:
-hackers) about this. I had been thinking along the lines of things that
would break pg_upgrade, not stuff that changes user APIs. It would be
difficult enough to get agreement on breaking pg_upgrade; I doubt a
release that breaks practically every tool created for Postgres is going
to get concensus, regardless of the version numbering.

I've tried (unsuccessfully) 3 times now to write an email starting that
discussion. I think this is an important topic that needs to be
discussed, but it's not clear how to even get that ball rolling. Even
without the inevitable flood of "Have you lost your mind?" type replies,
I don't that we even have a robust enough process to make an intelligent
decision. Sure, there could be wiki pages or something about this, but
those won't move discussion by themselves.

Maybe the first question that needs to be answered is how we can
actually move the community to an informed decision about this.

One thought did occur to me though... ISTM that since 10 is a big
milestone that should be celebrated that it's actually a bad target for
a major compatibility break. It would be better to do that with 11. I
think the timing probably works better too, 'cause I'd be amazed if we
were even able to get through that laundry list of issues in 2 years,
let alone 1.
--
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net

On Mon, Apr 11, 2016 at 11:13:57AM +0300, Oleg Bartunov wrote:
> On Mar 22, 2016 9:03 PM, "Josh berkus" <josh@agliodbs.com> wrote:
> >
> > On 03/22/2016 10:52 AM, Peter Geoghegan wrote:
> > > On Tue, Mar 22, 2016 at 10:41 AM, Josh berkus <josh@agliodbs.com> wrote:
> > >> It's important to remember that PR strategy and engineering truth have
> > >> only a passing acquaintance.  While we don't want to promote vaporware,
> > >> we do sometimes soft-pedal our own features to our project's detriment.
> > >> In the current atomosphere of VC-funded hype, we'd do a bit better to
> > >> trumpet our accomplishements early and often.
> > >
> > > I see what you mean.
> > >
> > > The question must be asked: What feature *would* meet that "major
> > > version bump" standard? If it's not extensive parallelism, then I
> > > don't know what else it could be.
> >
> > Well, if we had pglogical AND parallel, I would be pushing hard for
> > 10.0.  As it is, I was going to wait to see what else gets in.
> >
> > As it is, we have parallel and we have all of the BDR dependancies
> > merged in, no?  That still seems like a new era for PostgreSQL; I think
> > we can expect the next few releases to be all about (a) parallelizing
> > more things and (b) building out clustering stuff.
> >
> > One thing we don't much talk about is that we hit an inflection point
> > somewhere in the 9.X series, as demonstrated by CitusDB: it is now as
> > easy to build out your "Postgres Fork" by using our APIs and hooks as it
> > is by forking the project.  That's going to make a big difference for us
> > in the long run, possibly bigger than any individual feature.
>
> Well, API is enough to build non-transactional distributed databases. We
> proposed pluggable TM to go further. Hope  it will get more attention at
> pgcon.

I'd love to see the more progress on transaction management,
especially for distributed cases.

> BTW, what's about unforking pipelinedb ? Is't possible with our API and
> hooks ?

So long as what's in PipelineDB can be used in a useful sense without
patching its IP into core, this is feasible.

There are much larger issues around getting a startup essentially to
surrender its IP if patches are required in that sense.  Even assuming
that their investors and counsel would agree to do it, there are still
large, architectural issues.  As a rule, what's great in addressing a
niche market is usually terrible when building public infrastructure,
which is what PostgreSQL is about.  I agree we need to get streaming
capabilities, but I'm far from sure that getting them from a
proprietary project would actually be a shorter route to them than
building them ourselves.

> There is a big demand from russian  companies to Postgres and we are
> in difficult situation. Small steps forward is good, but it looks
> like we need hard thinking about our roadmap.

What situation in particular?  Is Oracle making moves to make using
PostgreSQL legally difficult?

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 04/10/2016 04:23 PM, Jim Nasby wrote:

>>  From that:
>>
>>    * SQL compliant identifiers
>>    * Remove RULEs
>>    * Change recovery.conf
>>    * Change block headers
>>    * Retire template0, template1
>>    * Optimise FSM
>>    * Add heap metapage
>>    * Alter tuple headers
>

[snip]

>
> I've tried (unsuccessfully) 3 times now to write an email starting that
> discussion. I think this is an important topic that needs to be
> discussed, but it's not clear how to even get that ball rolling. Even
> without the inevitable flood of "Have you lost your mind?" type replies,
> I don't that we even have a robust enough process to make an intelligent
> decision. Sure, there could be wiki pages or something about this, but
> those won't move discussion by themselves.
>
> Maybe the first question that needs to be answered is how we can
> actually move the community to an informed decision about this.
>

What is the problem we are trying to solve?

SQL compliant indentifiers? Is there a sizeable user base requesting this?

Remove Rules? Why?

Retire template0, template1? Why?

I think those are the questions we need answered. Having a list of what
might be done in the future to break compatibility without a statement
as to the problem they cause or how the process will fix that problem is
basically hand waiving.

(note there are a couple that are obvious, heap metapage, optimise FSM
etc...)

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, Apr 11, 2016 at 11:29 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
> (note there are a couple that are obvious, heap metapage, optimise FSM
> etc...)

But it's not obvious why those things require breaking compatibility,
and pgsql-advocacy is not the right mailing list to discuss that.
There has been no recent discussion of any of this on pgsql-hackers.

Basically, this discussion boils down to Simon suggesting that instead
of bumping the version to 10.0 when we have a particularly good
release with great features, as we did for 9.0 and 8.0, we should
instead do it when we're planning to make a large compatibility break,
something which the community has not agreed to do.  Moreover, as
somebody already pointed out upthread, if we do decide to do that at
some point, calling this release 10.0 doesn't preclude us from making
the big compatibility break 11.0, if and when it happens.  So instead
of talking about whether the features in 9.6 are good enough that it
deserves to be called 10.0, we've veered into talking about whether we
want to break compatibility at some point, which is a weird discussion
for an advocacy list to be having.

TBH, I kind of expected that 9.5 was going to end up being 10.0, since
we haven't had a second digit of "5" since the 6.x series of releases.
I think that 9.5 was a pretty good release - INSERT .. ON CONFLICT is
exciting, and BRIN and RLS are good too - but I think 9.6 is going to
be better.  I am of course biased, but I think parallel query - now
including parallel aggregate - is a great headline feature.  But we've
also got two other things that I think are really big.  First, we've
got synchronous_commit=remote_apply and multiple synchronous standbys,
so you can now set up a streaming replication cluster and get answers
from your read standbys that are guaranteed to reflect the latest
commits on the master.  Second, we've got a freeze map so that your
large database doesn't spend all of it's time uselessly re-freezing,
which should make it possible to run PostgreSQL on much larger data
sets.  That goes nicely with the fact that we also have a bunch of
scalability enhancements for many-socket machines, which are the sort
of machines where those larger data sets would perhaps be stored.
Apart from those big three (parallel query, remote_apply+multiple sync
standbys, freeze map), there are lots of other things and which one is
best will probably depend on taste, but they include a bunch of nifty
performance enhancements for postgres_fdw, snapshot too old to control
table bloat, pluggable index access methods including bloom indexes as
a sample implementation, ability to see lwlocks in pg_stat_activity,
VACUUM progress reporting, enhancements to index-only scans, phrase
full text search, k-nearest-neighbor support for the cube extension,
and a bunch of other stuff.

So, I think it's shaping up to be pretty great release.

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

On 11 Apr 2016, at 17:11, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Apr 11, 2016 at 11:29 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> (note there are a couple that are obvious, heap metapage, optimise FSM
>> etc...)
>
> But it's not obvious why those things require breaking compatibility,
> and pgsql-advocacy is not the right mailing list to discuss that.
> There has been no recent discussion of any of this on pgsql-hackers.

Good point.  Just emailed -hackers with a starter stub for it, so it can
be discussed there:

  http://www.postgresql.org/message-id/954A2020-828D-47E8-A57E-AEC3643FE390@postgresql.org

;)

+ Justin

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

On 04/11/2016 09:11 AM, Robert Haas wrote:
> On Mon, Apr 11, 2016 at 11:29 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
>> (note there are a couple that are obvious, heap metapage, optimise FSM
>> etc...)
>
> But it's not obvious why those things require breaking compatibility,
> and pgsql-advocacy is not the right mailing list to discuss that.

Agreed.

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.

All,

While we established a while ago that a break in the file format would
cause a bump of the major version, it's not the ONLY thing which will.

Personally, I'd like to see us go to 10.0 just based on Parallel query.
 Looking back at 9.0, 9.6 is very little like 9.0.

Part of the reason for that, frankly, is that our use of second version
numbers makes the project look slower moving than databases which
actually add fewer features. Particularly, it's not lost on me that the
first version of MariaDB was 10.0.

If this version isn't 10.0, then let's plan on next version being 10.0
based on the idea of having all of the migrate-in-place tools (i.e.
pglogical) ready to go.

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

On 04/11/2016 10:10 AM, Josh berkus wrote:
> All,
>
> While we established a while ago that a break in the file format would
> cause a bump of the major version, it's not the ONLY thing which will.
>
> Personally, I'd like to see us go to 10.0 just based on Parallel query.
>   Looking back at 9.0, 9.6 is very little like 9.0.

I am not sure a comparative of 9.6 -> 9.0 is fair, considering I can say
the exact same thing using 9.2 (and especially 9.3) instead of 9.6 as
the upcoming version number.

>
> Part of the reason for that, frankly, is that our use of second version
> numbers makes the project look slower moving than databases which
> actually add fewer features. Particularly, it's not lost on me that the
> first version of MariaDB was 10.0.

True but comparing ourselves to a company is the wrong way to go about it.

1. We should never consider it marketing, we aren't selling a product.
The mentality is also very different. When someone thinks of marketing
or advertising their is usually currency involved. When someone thinks
of advocacy and education, there is a different approach that helps
build the types of relationships we want.

2. Version *numbers* aren't nearly as identifiable as using names. This
is something that Ubuntu has on us and something we should consider. For
example, most people don't say I am running 15.10, they say, I am
running Wily.

3. We are advocating an Open Source project and should add the entire
ecosystem around it. I think one of our larger advocacy failures is that
although we are great at celebrating the .Org release, we ignore all the
other awesome pieces of software built explicitly for PostgreSQL that
would be advocating and demonstrating as a complete stack.

>
> If this version isn't 10.0, then let's plan on next version being 10.0
> based on the idea of having all of the migrate-in-place tools (i.e.
> pglogical) ready to go.

That seems reasonable.

Sincerely,

Joshua D. Drake



--
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 04/11/2016 10:23 AM, Joshua D. Drake wrote:
> 2. Version *numbers* aren't nearly as identifiable as using names. This
> is something that Ubuntu has on us and something we should consider. For
> example, most people don't say I am running 15.10, they say, I am
> running Wily.

FWIW, I regard Debian/Ubuntu names a huge barrier to adoption.  They're
a cute "insider" thing, but confusing to new users.

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

On 04/11/2016 10:35 AM, Josh berkus wrote:
> On 04/11/2016 10:23 AM, Joshua D. Drake wrote:
>> 2. Version *numbers* aren't nearly as identifiable as using names. This
>> is something that Ubuntu has on us and something we should consider. For
>> example, most people don't say I am running 15.10, they say, I am
>> running Wily.
>
> FWIW, I regard Debian/Ubuntu names a huge barrier to adoption.  They're
> a cute "insider" thing, but confusing to new users.

Interesting, that isn't my experience. Even customers say, "I am running
Precise or Trusty" and then I have to remember which version number that
is. Also, considering Ubuntu is by far the largest used Linux distro, I
am not sure how much of that is happening in practice.

I should note that I am not suggesting we forgo version names but adding
something that is fun could be useful... Something to think about.

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 04/11/2016 10:46 AM, Magnus Hagander wrote:

> Doesn't match my experience at all. The vast majority of my customers
> refer to it by version number.
>
>     Also, considering Ubuntu is by far the largest used Linux distro, I
>     am not sure how much of that is happening in practice.
>
>
> Also very different from my experience. Outside things like docker
> (which most people don't run postgres on - yet?), redhat/centos is
> significantly bigger with my customers.

I should clarify:

When dealing with bare metal -- by far our customer base is
RedHat/CentOS. When dealing with anything cloud, it is by far Debian or
Ubuntu.

>
> Just as a point of input - clearly our customers fall in fairly
> significantly different groups,and we need to be able to deal with both.
>

Absolutely.

>
>     I should note that I am not suggesting we forgo version names but
>     adding something that is fun could be useful... Something to think
>     about.
>
>
>
> FWIW, I believe redhat also has such "code names". Except really
> *nobody* use them there...

True.

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 04/11/2016 10:46 AM, Magnus Hagander wrote:
> On Mon, Apr 11, 2016 at 7:43 PM, Joshua D. Drake <jd@commandprompt.com
> <mailto:jd@commandprompt.com>> wrote:
>
>     On 04/11/2016 10:35 AM, Josh berkus wrote:
>
>         On 04/11/2016 10:23 AM, Joshua D. Drake wrote:
>
>             2. Version *numbers* aren't nearly as identifiable as using
>             names. This
>             is something that Ubuntu has on us and something we should
>             consider. For
>             example, most people don't say I am running 15.10, they say,
>             I am
>             running Wily.
>
>
>         FWIW, I regard Debian/Ubuntu names a huge barrier to adoption.
>         They're
>         a cute "insider" thing, but confusing to new users.
>
>
>     Interesting, that isn't my experience. Even customers say, "I am
>     running Precise or Trusty" and then I have to remember which version
>     number that is.

So, imagine that you're learning to use Ubuntu for the first time.

1. You find a software package which requires "Trusty or later".  How do
you know if you can run it?

2. "About" says you're running Ubuntu 14.04, but to sign up for an
alternate repo (like PostgreSQL), you need to sign up for it by name.
How do you figure out what the name is?

3. You have a bunch of servers running "Pangolin".  Do you need to worry
about upgrading those soon due to EOL?

4. You are running "Saucy".  How many upgrades have you missed?

This is worse for Debian, where the cute names aren't even alphabetical.
 Worst yet is Apple, where the names have no clear progression and are
stupidly similar (leopard vs. snow leopard).

The "cute names" thing assumes a insider level knowledge of mapping
names to releases; it assumes that you work with that distro *all the
time*.  Which is fairly hostile to newbies and people responsible for
administering hundreds of servers using a assortment of distros and
OSes.  I think Apple can count on that level of fanboyism; I don't think
anyone else should.

For that reason, I would be strongly opposed to adopting a "cute name"
scheme for Postgres.

>
> FWIW, I believe redhat also has such "code names". Except really
> *nobody* use them there...

Correct, they are used internally only.

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

On 04/11/2016 11:04 AM, Josh berkus wrote:

> For that reason, I would be strongly opposed to adopting a "cute name"
> scheme for Postgres.
>

I am not arguing against your logic, just stating what I run into.

>
> Correct, they are used internally only.
>

Right and I am not suggesting that we migrate to a policy where we
reference only (or even primarily) the "cute name".

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 04/11/2016 11:10 AM, Joshua D. Drake wrote:
> On 04/11/2016 11:04 AM, Josh berkus wrote:
>
>> For that reason, I would be strongly opposed to adopting a "cute name"
>> scheme for Postgres.
>>
>
> I am not arguing against your logic, just stating what I run into.

OK.  We just have a lot of Debian folks in the community, and I wanted
to jump in before that ran away ...

>>
>> Correct, they are used internally only.
>>
>
> Right and I am not suggesting that we migrate to a policy where we
> reference only (or even primarily) the "cute name".

So you're thinking just a release name until the number is assigned?
Would that benefit anything?

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

On 04/11/2016 11:18 AM, Josh berkus wrote:

>>>
>>> Correct, they are used internally only.
>>>
>>
>> Right and I am not suggesting that we migrate to a policy where we
>> reference only (or even primarily) the "cute name".
>
> So you're thinking just a release name until the number is assigned?
> Would that benefit anything?

I think there is something to be said for standing in front of a bunch
of non database people (say... newbie rails developers) and saying:

PostgreSQL is about to release 10.0, otherwise known as Buffalo stampede.

People will go, "what?"... then we talk about it and actually talk about
why we chose the name Buffalo stampede (note: that name literally just
spilled itself on to the screen, I haven't actually thought we would use
it).

Further, when we release 10.0, we tie into the name with further
branding and advocacy tie-ins. Maybe it is a picture of an elephant
conducting a orchestra of buffalo (parallel query), who knows.

Obviously I (or any other speaker) could just do that as part of their
talk and we would have 100s of names running around. Whereas if there is
a tie in to a purpose a way to get more people to think about the
project and software, that is a good thing.

And if we take that an tie it into things like an interview from Dzone
and say, "Magnus, second question (because the first is always, who are
you)" is: "So why Buffalo Stampede for 10.0?" and Magnus gets to go into
who parallel query represents a "stampede" of new performance
capabilities for PostgreSQL. That is a carrot to read the article and it
attracts better than, "PostgreSQL releases 10.0 with more performance
improvements!".

Sincerely,

JD

P.S. Please keep in mind that all of this is literally just off the top
of my head and I am not suggesting that we just run with it. I am just
spilling coffee on the keyboard of ideas.

--
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 04/11/2016 11:32 AM, Joshua D. Drake wrote:
> On 04/11/2016 11:18 AM, Josh berkus wrote:
>
>>>>
>>>> Correct, they are used internally only.
>>>>
>>>
>>> Right and I am not suggesting that we migrate to a policy where we
>>> reference only (or even primarily) the "cute name".
>>
>> So you're thinking just a release name until the number is assigned?
>> Would that benefit anything?
>
> I think there is something to be said for standing in front of a bunch
> of non database people (say... newbie rails developers) and saying:
>
> PostgreSQL is about to release 10.0, otherwise known as Buffalo stampede.

I don't get the value here.

And I spend a lot of time with junior developers.  Thing is, the New
Cool Tools (Docker, Rust, Node, GoLang, etc.) *don't* use release names.
 This implies that cute release names are passe'.

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

On 04/11/2016 11:41 AM, Josh berkus wrote:
> On 04/11/2016 11:32 AM, Joshua D. Drake wrote:
>> On 04/11/2016 11:18 AM, Josh berkus wrote:
>>
>>>>>
>>>>> Correct, they are used internally only.
>>>>>
>>>>
>>>> Right and I am not suggesting that we migrate to a policy where we
>>>> reference only (or even primarily) the "cute name".
>>>
>>> So you're thinking just a release name until the number is assigned?
>>> Would that benefit anything?
>>
>> I think there is something to be said for standing in front of a bunch
>> of non database people (say... newbie rails developers) and saying:
>>
>> PostgreSQL is about to release 10.0, otherwise known as Buffalo stampede.
>
> I don't get the value here.
>
> And I spend a lot of time with junior developers.  Thing is, the New
> Cool Tools (Docker, Rust, Node, GoLang, etc.) *don't* use release names.
>   This implies that cute release names are passe'.

Shrug, o.k., like I said -- just ideas off the keyboard. However, that
doesn't reduce the quality of some of the other ideas (like making sure
we get something like a DZone interview).

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 04/11/2016 11:50 AM, Joshua D. Drake wrote:

> Shrug, o.k., like I said -- just ideas off the keyboard. However, that
> doesn't reduce the quality of some of the other ideas (like making sure
> we get something like a DZone interview).

That would be nice.  Know anyone there?


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

On 04/11/2016 11:51 AM, Josh berkus wrote:
> On 04/11/2016 11:50 AM, Joshua D. Drake wrote:
>
>> Shrug, o.k., like I said -- just ideas off the keyboard. However, that
>> doesn't reduce the quality of some of the other ideas (like making sure
>> we get something like a DZone interview).
>
> That would be nice.  Know anyone there?

I do, as well as Infoworld and possible SD Times.

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 wrote
> TBH, I kind of expected that 9.5 was going to end up being 10.0, since
> we haven't had a second digit of "5" since the 6.x series of releases.
> I think that 9.5 was a pretty good release - INSERT .. ON CONFLICT is
> exciting, and BRIN and RLS are good too - but I think 9.6 is going to
> be better.

I got clued in via the cross-post down-list to hackers but figured I'd jump
off from here.

In brief, my take-away from this thread is that we should institute a policy
of introducing a new "N.0" release whenever the "N-1.0" release is no longer
supported.  As part of the N.0 release we should make a concerted effort to:

1) Communicate that our last great thing (e.g. 9.0) is now is no longer
supported.
2) Communicate to the people who don't follow the second-digit releases all
of the great stuff that has been added since 9.0 that you get by moving to
10.0 - above and beyond being officially supported.

To some degree this would solidify Robert's subconscious thought that 9.5
could have warranted being made 10.0 and the fact that neither 7 nor 8 made
it past 4 yet here was are pushing out 6.

The specific timing decision surrounding the end of supporting N-1.0 and the
release of N.0 would probably want to be tweaked to work hand-in-hand with
this public-facing aspect but that should be easy if the general premise is
agreed to.

The N.0 release then becomes a combination of a normal release as well as a
historical re-release and ideally some degree of telling a story of how the
previous 5 years progressed to try and establish a closer connection with
the larger community.

David J.




--
View this message in context: http://postgresql.nabble.com/9-6-10-0-tp5894473p5898124.html
Sent from the PostgreSQL - advocacy mailing list archive at Nabble.com.

On Mon, Apr 11, 2016 at 08:29:07AM -0700, Joshua Drake wrote:
> On 04/10/2016 04:23 PM, Jim Nasby wrote:
>
> >> From that:
> >>
> >>   * SQL compliant identifiers
> >>   * Remove RULEs
> >>   * Change recovery.conf
> >>   * Change block headers
> >>   * Retire template0, template1
> >>   * Optimise FSM
> >>   * Add heap metapage
> >>   * Alter tuple headers
> >
>
> [snip]
>
...
> What is the problem we are trying to solve?
>
> SQL compliant indentifiers? Is there a sizeable user base requesting this?
>
> Remove Rules? Why?
>
> Retire template0, template1? Why?
>
> I think those are the questions we need answered. Having a list of what
> might be done in the future to break compatibility without a statement as to
> the problem they cause or how the process will fix that problem is basically
> hand waiving.
>
> (note there are a couple that are obvious, heap metapage, optimise FSM
> etc...)

I was worried that pg_upgrade would block on-disk format changes and
cause a huge pile up of non-optimal storage requirements, but after
seven years (since 2009) is that the biggest list we can come up with?
As far as I am concerned, it doesn't come anywhere near requiring all
users to dump/restore.

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

Hi,

I read every email in this thread. Thanks everyone who contributed. 

However, my point still did not change. The upcoming features in 9.6 is no less
than 9.0 or 8.0 -- even more. Apart from the feature list, the infrastructural
changes in 9.6 is a bit too much, so we should warn the users about that, with
a .0 release. I, as a person from the field, will raise warnings to my
customers about that, for example.

An argument about "we can have 10.0 release if we have this feature" is also
*very* conservative: No one is stopping us for 11.0 release, when we have those
cool features with those major breakages. 

Eventually, before releasing 9.6beta1, to make the packagers lives easier, I
want to push for a change again. Let's stop being conservative, and mark this
release as 10.0.

Regards, Devrim

On Tue, 2016-03-22 at 16:07 +0200, Devrim GÜNDÜZ wrote:
> Hi,
>
> I've been ranting about this on Twitter for a while, and now blogged about
> it:
>
> http://people.planetpostgresql.org/devrim/index.php?/archives/89-9.6,-or-10.0
> .html
>
> There are major changes in 9.6 (some of them are listed in the blog post),
> and
> I think they are good enough to call this 10.0.
>
> A counter argument might be waiting for pglogical for inclusion, but I think
> the current changes are enough to warrant a .0 release.
>
> What do you think?
>
> Regards,

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 05/09/2016 08:39 AM, Devrim Gündüz wrote:

> Eventually, before releasing 9.6beta1, to make the packagers lives easier, I
> want to push for a change again. Let's stop being conservative, and mark this
> release as 10.0.

The argument boils down to this:

There is no technical reason to name it 10.0 so why would we?

Because it grants a larger advocacy opportunity and shows the amount of
effort that went into 9.6Devel/10.0.

There is every advocacy reason to name it 10.0 so why wouldn't we?

Because it will potentially cheapen the value of moving to 11.0 unless
we are predictably conservative about our release versioning process.

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.

Hi,

On Mon, 2016-05-09 at 08:53 -0700, Joshua D. Drake wrote:
> The argument boils down to this:
>
> There is no technical reason to name it 10.0 so why would we?

The reasons have been discussed in all details in this thread. I won't repeat
them in here, but the list is big, as you know.

> Because it grants a larger advocacy opportunity and shows the amount of 
> effort that went into 9.6Devel/10.0.
>
> There is every advocacy reason to name it 10.0 so why wouldn't we?

+technical reasons...

> Because it will potentially cheapen the value of moving to 11.0 unless 
> we are predictably conservative about our release versioning process.

Oh, does it mean that in-core replication or Windows support or PITR also
cheapened our release versioning process? I don't think so.

Fedora and Firefox already got rid of this ego ;)

Cheers,

--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR

On 05/09/2016 08:53 AM, Joshua D. Drake wrote:
> On 05/09/2016 08:39 AM, Devrim Gündüz wrote:
>
>> Eventually, before releasing 9.6beta1, to make the packagers lives
>> easier, I
>> want to push for a change again. Let's stop being conservative, and
>> mark this
>> release as 10.0.
>
> The argument boils down to this:

Thanks for summary, doing my best to take these arguments head-on.

>
> There is no technical reason to name it 10.0 so why would we?

Because there has never before been a "technical" reason for a major
version number, so why is that the criterion now?   People keep talking
about breaking the file format, but since nobody has plans to do that in
the next 2 releases, it's a stupid reason for waiting.

There are two solid reasons to call this release 10.0:

1. We've added parallel query, a feature which has been on the TODO list
for well over a decade.

2. We've got a greater-thank-average number of features which could
cause instability/corruption bugs, so users should treat this upgrade
with caution.

Also a third, weaker one:

3. pglogical will probably reach release quality before next year,
making this release the "hot upgrade" release.

> Because it grants a larger advocacy opportunity and shows the amount of
> effort that went into 9.6Devel/10.0.
>
> There is every advocacy reason to name it 10.0 so why wouldn't we?
>
> Because it will potentially cheapen the value of moving to 11.0 unless
> we are predictably conservative about our release versioning process.

We have always been overly conservative about major version numbers.
The result is having our users talk about "Postgres 9" like there's been
no significant changes since 9.0.  It makes it look like we're not
making progress, something which competing communities take advantage of
(such as MariaDB: if you think it's a coincidence they jumped their
version number to one higher than ours, think again).

Further, none of the "game-changer" features talked about for the next
release are high-certainty.  So there's a significant probability that
9.7 will still not be "good enough" to be 10.0, and we won't switch to
10.0 until we're forced to because of 9.9.  It's goofy, it's like
someone is charging us for version numbers.

I'm in favor of 10.0.  It's time.

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

On 05/09/2016 09:07 AM, Devrim Gündüz wrote:

> Oh, does it mean that in-core replication or Windows support or PITR also
> cheapened our release versioning process? I don't think so.
>
> Fedora and Firefox already got rid of this ego ;)

I think you are missing my point. What I was trying to say is that
neither side is wrong and there are pros and cons to both.

Frankly, I have lost interest in the argument. I can and will advocate
either a 9.6 or a 10.0 equally, it just takes a change in message. I am
more interested in the message at this point than some arbitrary number
invents on -hackers.

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 05/09/2016 09:42 AM, Magnus Hagander wrote:
>

>     > Because it grants a larger advocacy opportunity and shows the amount of
>     > effort that went into 9.6Devel/10.0.
>     >
>     > There is every advocacy reason to name it 10.0 so why wouldn't we?
>     >
>     > Because it will potentially cheapen the value of moving to 11.0 unless
>     > we are predictably conservative about our release versioning process.
>
>
> Are you saying it's 10.0 that has a special magic meaning, or just the
> bump of the super-major version number or whatever we call it?
>
> I'm not sure I buy that argument in general. There's *always* going to
> be a next release.
>
> And we already have a version numbering scheme that confuses people :)
>

I am saying that lesser mortals by default will think something is
cooler, hotter, more awesome than reality based on a large version jump.
It is a proven marketing method.

But see my earlier post about just wanting a decision. In short, could
-core or the release team review the thread, provide some leadership and
let us all get on with it?

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, May 9, 2016 at 9:16 AM, Josh berkus <josh@agliodbs.com> wrote:
>> There is no technical reason to name it 10.0 so why would we?
>
> Because there has never before been a "technical" reason for a major
> version number, so why is that the criterion now?

Exactly.

> We have always been overly conservative about major version numbers.
> The result is having our users talk about "Postgres 9" like there's been
> no significant changes since 9.0.

I think that sticking with the same major version number forever
serves no purpose. Linux changed their approach here, so there were
far fewer 3.* kernels than 2.* kernels. I don't understand how an
insurmountable standard for bumping major versions numbers helps
anything. Linux only got about 4 years out of 3.*, and that change was
for expressly non-technical reasons.

--
Regards,
Peter Geoghegan

On 05/09/2016 01:58 PM, Magnus Hagander wrote:

> So this is probably just highlighting how I'm not up to date on the
> -advocacy discussion :) But I thought the idea was to have it
> integrated, and that *that* was "the product" in this case. As in the
> "breaker that makes it possible to do transparent upgrades without
> external products". Which I thought was the target for next release, not
> this release. But I may be confusing multiple discussion, and as such
> contributing to the confusion.

Yeah, there's multiple discussions, at least 2:

1. Should we promote pglogical in the beta as something to *test*?

2. Is pglogical a major-version-making feature?

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

> On 05/09/2016 01:58 PM, Magnus Hagander wrote:
>
>> So this is probably just highlighting how I'm not up to date on the
>> -advocacy discussion :) But I thought the idea was to have it
>> integrated, and that *that* was "the product" in this case. As in the
>> "breaker that makes it possible to do transparent upgrades without
>> external products". Which I thought was the target for next release, not
>> this release. But I may be confusing multiple discussion, and as such
>> contributing to the confusion.
>
> Yeah, there's multiple discussions, at least 2:
>
> 1. Should we promote pglogical in the beta as something to *test*?
>
> 2. Is pglogical a major-version-making feature?
>

In my opinion when we have a visual environment full amdinistración
included in the core, will be version 10 while not.

Saludos,
Gilberto Castillo
ETECSA, La Habana, Cuba

On 05/09/2016 02:04 PM, Gilberto Castillo wrote:
>
>> On 05/09/2016 01:58 PM, Magnus Hagander wrote:
>>
>>> So this is probably just highlighting how I'm not up to date on the
>>> -advocacy discussion :) But I thought the idea was to have it
>>> integrated, and that *that* was "the product" in this case. As in the
>>> "breaker that makes it possible to do transparent upgrades without
>>> external products". Which I thought was the target for next release, not
>>> this release. But I may be confusing multiple discussion, and as such
>>> contributing to the confusion.
>>
>> Yeah, there's multiple discussions, at least 2:
>>
>> 1. Should we promote pglogical in the beta as something to *test*?
>>
>> 2. Is pglogical a major-version-making feature?
>>
>
> In my opinion when we have a visual environment full amdinistración
> included in the core, will be version 10 while not.

That is not in anybody's plans for PostgreSQL.  Assuming you mean a GUI?

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

> On 05/09/2016 02:04 PM, Gilberto Castillo wrote:
>>
>>> On 05/09/2016 01:58 PM, Magnus Hagander wrote:
>>>
>>>> So this is probably just highlighting how I'm not up to date on the
>>>> -advocacy discussion :) But I thought the idea was to have it
>>>> integrated, and that *that* was "the product" in this case. As in the
>>>> "breaker that makes it possible to do transparent upgrades without
>>>> external products". Which I thought was the target for next release,
>>>> not
>>>> this release. But I may be confusing multiple discussion, and as such
>>>> contributing to the confusion.
>>>
>>> Yeah, there's multiple discussions, at least 2:
>>>
>>> 1. Should we promote pglogical in the beta as something to *test*?
>>>
>>> 2. Is pglogical a major-version-making feature?
>>>
>>
>> In my opinion when we have a visual environment full amdinistración
>> included in the core, will be version 10 while not.
>
> That is not in anybody's plans for PostgreSQL.  Assuming you mean a GUI?

Yes, Here everything compared to MS-SQLServer and Oracle wise it is topic.

--
Saludos,
Gilberto Castillo
ETECSA, La Habana, Cuba

On 05/09/2016 02:00 PM, Josh berkus wrote:
> On 05/09/2016 01:58 PM, Magnus Hagander wrote:
>
>> So this is probably just highlighting how I'm not up to date on the
>> -advocacy discussion :) But I thought the idea was to have it
>> integrated, and that *that* was "the product" in this case. As in the
>> "breaker that makes it possible to do transparent upgrades without
>> external products". Which I thought was the target for next release, not
>> this release. But I may be confusing multiple discussion, and as such
>> contributing to the confusion.
>
> Yeah, there's multiple discussions, at least 2:
>
> 1. Should we promote pglogical in the beta as something to *test*?
>

I believe I mentioned in the past that I do think it is a reasonable
idea to promote it. The question is with what message.

> 2. Is pglogical a major-version-making feature?

Not if it isn't in core.

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 2016-05-09 9:16 AM, Josh berkus wrote:
> Because there has never before been a "technical" reason for a major
> version number, so why is that the criterion now?   People keep talking
> about breaking the file format, but since nobody has plans to do that in
> the next 2 releases, it's a stupid reason for waiting.

I would advocate changing to be aggressive with version number increases and
adapting a stricter semantic versioning.

See also what SQLite did recently as prior art:

https://www.sqlite.org/versionnumbers.html

Loosely speaking, have at least MAJOR.MINOR.PATCH.MATURITY components,
optionally more.  MAJOR must be increased when a backwards-compatibility break
is made of any kind (such as removing a feature), otherwise MINOR must be
increased for any forwards-compatibility break (such as adding a feature),
otherwise PATCH must be increased for changes that shouldn't break any kind of
compatibility, except for fixing bugs or security holes where the old behavior
was not being relied on for any working uses.  MATURITY means eg
alpha/beta/rc/production etc.

The version numbers reflect substitutability of versions.  With respect to
Postgres this means both changes to the file format and changes to the API.

Any situation where the file format changes such that you can not simply stop
the server, swap the binaries, and restart and have it just work, is considered
a breaking change.  If you can not swap to a newer version from an older one,
increment MAJOR; if you can do that but you can't switch back to the older one
from that newer, increment MINOR.

What I describe is simply situations where a version part MUST be increased;
they can also be increased at other times say for marketing reasons.

If a PATCH version accidentally broke something, another PATCH should be issued
which reverses it, so the promise to users on substitutability is maintained.

Note that I had been thinking about these matters more in depth as I adapted
that scheme for my own projects following SQLite doing so.

-- Darren Duncan

On 05/09/2016 03:18 PM, Darren Duncan wrote:
> Loosely speaking, have at least MAJOR.MINOR.PATCH.MATURITY components,
> optionally more.  MAJOR must be increased when a backwards-compatibility
> break is made of any kind (such as removing a feature), otherwise MINOR
> must be increased for any forwards-compatibility break (such as adding a
> feature), otherwise PATCH must be increased for changes that shouldn't
> break any kind of compatibility, except for fixing bugs or security
> holes where the old behavior was not being relied on for any working
> uses.  MATURITY means eg alpha/beta/rc/production etc.

That seems like that would be an argument against 10.0?  Since we didn't
break backwards compat?

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

On Mon, May 9, 2016 at 4:24 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> The question is whether others take an interest in doing the same thing for
> pglogical. I suggest that it is more about acceptance of the technology than
> it is about software quality, which is easy to measure. Perhaps that is just
> a matter of time.

Hmm, I don't agree with that.  Craig Ringer said on February 18th that
"I'm not sure anyone takes the pglogical downstream submission as a
serious attempt at inclusion in 9.6".  That was news to me; I had
hoped very much that it was a serious attempt at inclusion in 9.6.
But when I read the patch it became clear pretty quickly that his
statement was accurate.  The patch was not in a state where anyone
could seriously think of committing it, and it had many problems which
obviously could have been fixed prior to submission.  To take just one
example, the documentation was in markdown, not SGML, but more than
that, it would have needed a heavy rewriting to match the style of the
PostgreSQL documentation.  It's not like Craig Ringer and Petr Jelinek
don't know what PostgreSQL documentation needs to look like.  The
code, too, is in need of more work.

On top of that, when various people provided review comments, they
never resulted in an updated patch.  The original post was December
31st.  By January 10th, it had been reviewed by two people.  By
January 17th, they'd both asked for an updated patch to be posted with
a fix for a bug that had been uncovered in review.  More than three
months later, there's still no new patch on that thread.  Yeah,
there's probably updated code in the 2ndQuadrant repository, but
that's never been an acceptable way of submitting an updated patch.
This code may be doing great (or terrible, for all I know) as a
third-party product that works with PostgreSQL, but that's a different
project from making it part of PostgreSQL.

I think it's abundantly clear that there is a consensus for logical
replication in core.  There's more disappointment about the lack of
that feature in this release on this thread than any other.  I, too,
have supported the idea of logical replication in PostgreSQL at every
stage - for example, I wrote
http://rhaas.blogspot.com/2011/02/case-for-logical-replication.html
before I had any idea who might develop such a feature, and I
committed Andres's work on logical decoding.  I believe there is was
real political problem with getting logical replication into
PostgreSQL core in 9.6, and I believe there will be no problem getting
into into core in 9.7, whether as pglogical or in some other form.
There has been no serious opposition to the concept of logical
replication in PostgreSQL core for several years.  But somebody's got
to do the work.  That means somebody's got to submit something that
looks like a committable patch and be prepared to do several rounds of
timely revision of that patch as review comments arrive.  Andres is
willing to review such a patch and I am, too.

So, I think this *is* about software quality.  pglogical didn't miss
9.6 because hate got dumped on it; I would have been delighted to see
it go into 9.6, as that would have been another point in favor of
calling this release 10.0.  It missed 9.6 because of a lack of effort.

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

On Mon, May 9, 2016 at 5:00 PM, Josh berkus <josh@agliodbs.com> wrote:
> 1. Should we promote pglogical in the beta as something to *test*?

No.  But the reason depends on the answer to this question: Is
pglogical a core submission or a third-party product?

If it's the former, then getting people to test such things is the
purpose of a CommitFest, not a beta announcement, and in fact it did
get tested and reviewed as part of the CommitFest just like many other
patches which were also submitted, except that it got more enthusiasm
than many until it became clear that no updates in response to review
comments would be forthcoming.

If it's the latter, then we don't promote third-party products in beta
announcements; 2ndQuadrant can make their own announcements about
pglogical in accordance with
https://wiki.postgresql.org/wiki/NewsEventsApproval just like anyone
else.

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

On 05/09/2016 03:52 PM, Robert Haas wrote:
> On Mon, May 9, 2016 at 5:00 PM, Josh berkus <josh@agliodbs.com> wrote:
>> 1. Should we promote pglogical in the beta as something to *test*?
>
> If it's the latter, then we don't promote third-party products in beta
> announcements; 2ndQuadrant can make their own announcements about
> pglogical in accordance with
> https://wiki.postgresql.org/wiki/NewsEventsApproval just like anyone
> else.

Right. I don't have a problem and am actually 100% behind
cross-promoting "projects" but products are a business problem not a
.Org problem.

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 2016-05-09 3:24 PM, Josh berkus wrote:
> On 05/09/2016 03:18 PM, Darren Duncan wrote:
>> Loosely speaking, have at least MAJOR.MINOR.PATCH.MATURITY components,
>> optionally more.  MAJOR must be increased when a backwards-compatibility
>> break is made of any kind (such as removing a feature), otherwise MINOR
>> must be increased for any forwards-compatibility break (such as adding a
>> feature), otherwise PATCH must be increased for changes that shouldn't
>> break any kind of compatibility, except for fixing bugs or security
>> holes where the old behavior was not being relied on for any working
>> uses.  MATURITY means eg alpha/beta/rc/production etc.
>
> That seems like that would be an argument against 10.0?  Since we didn't
> break backwards compat?

To be clear, I am talking about backwards compatibility in a holistic sense,
both API *and* database cluster file format.

0.  Start with the context of a standalone (not replicated) Postgres 9.5
database cluster D1 and Postgres 9.5 binaries P1 and an application A1 using
those.  A1 also includes the set of SQL/etc queries made manually by users.

1.  Shutdown the Postgres servers P1, install new Postgres 9.6 binaries P2,
start Postgres servers P2, this all without making any changes to D1 or A1 which
includes not running pg_upgrade etc.

2.  Use A1 for awhile without making any changes to it.

3.  Shutdown the Postgres 9.6 servers P2, reinstall or use the previous Postgres
9.5 binaries P1, start Postgres servers P1.

If despite switching to 9.6 and then back to 9.5 without making any changes to
the application, everything just keeps working, then 9.6 is backwards-compatible
with 9.5 in the holistic sense.

When using 9.6 in the same way as 9.5 was used breaks the ability to use a
database cluster as is with 9.5, backwards compatibility is broken.

-- Darren Duncan

So, I have a simplified proposal, inspired by David G's comments.

Get rid of the middle number entirely.  Increment the first number for every
major version, use the second number to indicate patches.

So then the major releases from now on would be 10.0, 11.0, 12.0 etc.

Then this whole thread is bike shedding we can avoid.  No need to justify 9.x vs
10 etc which is heavily arbitrary.

EVERY major release is quite significant, so just give them all a new high
number, the end?

Would this satisfy everyone?

As such, assuming this proposal is adopted, I firmly support 10.0 for the next
major.

Whereas, if this proposal is not adopted, I see no strong reason to pick a
winner between 9.6 and 10.0.

-- Darren Duncan

On 2016-05-09 5:44 PM, David G. Johnston wrote:
> On Mon, May 9, 2016 at 5:19 PM, Darren Duncan <darren@darrenduncan.net>wrote:
>
>     On 2016-05-09 3:24 PM, Josh berkus wrote:
>
>         On 05/09/2016 03:18 PM, Darren Duncan wrote:
>
>             Loosely speaking, have at least MAJOR.MINOR.PATCH.MATURITY components,
>             optionally more.  MAJOR must be increased when a backwards-compatibility
>             break is made of any kind (such as removing a feature), otherwise MINOR
>             must be increased for any forwards-compatibility break (such as adding a
>             feature), otherwise PATCH must be increased for changes that shouldn't
>             break any kind of compatibility, except for fixing bugs or security
>             holes where the old behavior was not being relied on for any working
>             uses.  MATURITY means eg alpha/beta/rc/production etc.
>
>         That seems like that would be an argument against 10.0?  Since we didn't
>         break backwards compat?
>
>     To be clear, I am talking about backwards compatibility in a holistic sense,
>     both API *and* database cluster file format.
>
>     0.  Start with the context of a standalone (not replicated) Postgres 9.5
>     database cluster D1 and Postgres 9.5 binaries P1 and an application A1 using
>     those.  A1 also includes the set of SQL/etc queries made manually by users.
>
>     1.  Shutdown the Postgres servers P1, install new Postgres 9.6 binaries P2,
>     start Postgres servers P2, this all without making any changes to D1 or A1
>     which includes not running pg_upgrade etc.
>
>     2.  Use A1 for awhile without making any changes to it.
>
>     3.  Shutdown the Postgres 9.6 servers P2, reinstall or use the previous
>     Postgres 9.5 binaries P1, start Postgres servers P1.
>
>     If despite switching to 9.6 and then back to 9.5 without making any changes
>     to the application, everything just keeps working, then 9.6 is
>     backwards-compatible with 9.5 in the holistic sense.
>
>     When using 9.6 in the same way as 9.5 was used breaks the ability to use a
>     database cluster as is with 9.5, backwards compatibility is broken.
>
> ​Default maturity is "production" - we introduce beta, etc... at the end of a
> release cycle.
>
> I'm highly doubtful we could go an entire year without introducing a backward
> incompatibility - and to date we've never attempted to avoid doing so.  Thus
> what this proposal boils down to is:
>
> Major.Patch[.Maturity]
>
> Minor would never be incremented and would constitute harmful noise (it would
> imply potential that doesn't practically exist) if specified explicitly

I agree with you.  Having the separate MINOR is more of a project-agnostic mold
and for Postgres doesn't really help when the rules would make incrementing
MAJOR what is done for nearly every break.  Having MINOR works much better for
say SQLite who haven't had a backwards-compatibility break in over 13 years.

> IOW - We should just go to 10.0 in lieu of a 9.7 release, all then bug-fix
> releases increment 10.1, 10.2, 10.3, etc..., and two years from now we release 11.0

I agree/believe that if Postgres went with a semantic versioning scheme, it
should start off with a MAJOR increase to more clearly mark when the regime
change happened, as you say.

Or even if we essentially kept things as they are now, getting rid of the middle
number is helpful.  Just increment the first number for every major release and
the second number for bug fixes.  Then we can avoid all the bikeshedding of this
thread.

> Semantic versioning has become more prevalent as more and more project have
> either weekly/monthly cycles OR indefinite cycles where the increment will
> depend on what just got patched at any given point in time.  PostgreSQL doesn't
> fit into either of those molds so 4+ semantic levels just doesn't make sense.

I agree.

> ​I'm sticking to my opinion that because of our present numbering scheme and our
> 5-year support cycle we should increment major accordingly to those project
> policies and should consider aligning advocacy on that time pulse so certain
> aspects are emphasized during years 0,1,2,3,4 of the release cycle.  But, then
> again, I'm not close enough to this to say that what we have now is even broken
> and warrants changing.  All I have is an unproven setup based upon logic and
> symmetry with only minimal practical experience in advocacy.​

-- Darren Duncan

On 2016-05-09 6:30 PM, David G. Johnston wrote:
> On Mon, May 9, 2016 at 6:06 PM, Darren Duncan <darren@darrenduncan.net>wrote:
>     As such, assuming this proposal is adopted, I firmly support 10.0 for the
>     next major.
>
> ​Two things...
>
> Are we inclined to change this once we release Beta 1?
>
> Does the person in charge of tagging the repo, i.e. Tom Lane, watch -advocacy?

I would expect the version number to be mutable through the beta phase, and only
be locked down once the first release candidate is out. -- Darren Duncan

On 2016-05-09 6:49 PM, David G. Johnston wrote:
> On Mon, May 9, 2016 at 6:38 PM, Darren Duncan <darren@darrenduncan.net>wrote:
>     On 2016-05-09 6:30 PM, David G. Johnston wrote:
>         Are we inclined to change this once we release Beta 1?
>
>         Does the person in charge of tagging the repo, i.e. Tom Lane, watch
>         -advocacy?
>
>     I would expect the version number to be mutable through the beta phase, and
>     only be locked down once the first release candidate is out. -- Darren Duncan
>
> ​I would expect it to be locked down as soon as we start making public
> announcements about it - which happens when beta1 goes out.  In this case I'd
> accept choosing 10.0 but upon reverting half the features as being not ready
> changing back to 9.6; I don't really buy increasing it post-beta1 when no
> material changes have occurred - and I think we'd look somewhat silly trying.
>
> That said I seem to recall that the decision to number 9.0 came relatively late
> in the release cycle.  I'm not inclined to go research when I suspect quite a
> few people on this list can recall the facts from memory.

This has nothing to do with features, it is just a label.  The features should
be exactly the same whether this is called 9.6 or 10.0.  There is no
justification to make any changes to features just because the label was changed
from 9.6 to 10.0 during the beta stream.  Basically explain as there never was a
formal 9.6 series, it was always just 10.0, and 9.6 was an internal name during
development.  The numbers only really "count" for production-ready versions, not
in-development ones like betas. -- Darren Duncan

By the way, don't get me wrong.  If we stick to 9.6 for the current release I'm
perfectly happy with that, and would even prefer it for aesthetics reasons, as
AFAIK we never got to a .6 before.  The more general principle of just going
10,11,12 etc can start the next time, mainly to avoid ever having the kind of
needless bike-shedding in this discussion. -- Darren Duncan

On 2016-05-09 7:36 PM, Darren Duncan wrote:
> On 2016-05-09 6:49 PM, David G. Johnston wrote:
>> On Mon, May 9, 2016 at 6:38 PM, Darren Duncan <darren@darrenduncan.net>wrote:
>>     On 2016-05-09 6:30 PM, David G. Johnston wrote:
>>         Are we inclined to change this once we release Beta 1?
>>
>>         Does the person in charge of tagging the repo, i.e. Tom Lane, watch
>>         -advocacy?
>>
>>     I would expect the version number to be mutable through the beta phase, and
>>     only be locked down once the first release candidate is out. -- Darren Duncan
>>
>> ​I would expect it to be locked down as soon as we start making public
>> announcements about it - which happens when beta1 goes out.  In this case I'd
>> accept choosing 10.0 but upon reverting half the features as being not ready
>> changing back to 9.6; I don't really buy increasing it post-beta1 when no
>> material changes have occurred - and I think we'd look somewhat silly trying.
>>
>> That said I seem to recall that the decision to number 9.0 came relatively late
>> in the release cycle.  I'm not inclined to go research when I suspect quite a
>> few people on this list can recall the facts from memory.
>
> This has nothing to do with features, it is just a label.  The features should
> be exactly the same whether this is called 9.6 or 10.0.  There is no
> justification to make any changes to features just because the label was changed
> from 9.6 to 10.0 during the beta stream.  Basically explain as there never was a
> formal 9.6 series, it was always just 10.0, and 9.6 was an internal name during
> development.  The numbers only really "count" for production-ready versions, not
> in-development ones like betas. -- Darren Duncan

On 05/09/2016 06:06 PM, Darren Duncan wrote:
> So, I have a simplified proposal, inspired by David G's comments.
>

Both of these proposals are extremely elaborate solutions to a simple
problem which is resolvable via discussion.

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

On 05/09/2016 07:47 PM, Darren Duncan wrote:
> By the way, don't get me wrong.  If we stick to 9.6 for the current
> release I'm perfectly happy with that, and would even prefer it for
> aesthetics reasons, as AFAIK we never got to a .6 before.  The more
> general principle of just going 10,11,12 etc can start the next time,
> mainly to avoid ever having the kind of needless bike-shedding in this
> discussion. -- Darren Duncan

If we used the above versioning scheme we would be releasing: 24
(assuming we started at 1 instead of Pg95). I am not interested in an
Emacs or Fedora release scheme.

Also, if you think that moving to that scheme will change anything you
are wrong. It will just introduce different problems. The argument we
are having now is a once every couple to several year argument based on
pending significant features. If we had it for every release perhaps
there is a problem to fix but we don't.

The only flat rule solution I can see that might be reasonable was the
suggestion that no major release be > .5 but even then, why?

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 10/05/16 00:46, Robert Haas wrote:
> On Mon, May 9, 2016 at 4:24 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> The question is whether others take an interest in doing the same thing for
>> pglogical. I suggest that it is more about acceptance of the technology than
>> it is about software quality, which is easy to measure. Perhaps that is just
>> a matter of time.
>
> Hmm, I don't agree with that.

Please note that the discussion you are replying to is about pglogical
extension being ready for use with 9.6 release, not about in-core inclusion.

> Craig Ringer said on February 18th that
> "I'm not sure anyone takes the pglogical downstream submission as a
> serious attempt at inclusion in 9.6".  That was news to me; I had
> hoped very much that it was a serious attempt at inclusion in 9.6.

Well as of 18th February it was clear that it's going to be hard to push
it in core as the progress of polishing was slower than what was
necessary, both in terms of our development and the community review of
the more complex parts of the submission. But given the patch size and
the amount of other patches in the queue that's understandable. Craig's
comment should be taken in this context not in the context of original
submission as you seem to be doing.

> But when I read the patch it became clear pretty quickly that his
> statement was accurate.  The patch was not in a state where anyone
> could seriously think of committing it, and it had many problems which
> obviously could have been fixed prior to submission.  To take just one
> example, the documentation was in markdown, not SGML, but more than
> that, it would have needed a heavy rewriting to match the style of the
> PostgreSQL documentation.  It's not like Craig Ringer and Petr Jelinek
> don't know what PostgreSQL documentation needs to look like.
>

I am sorry but I don't really get this. We have had READMEs explaining
things before and we even have some in the core. Yes there should
eventually be sgml docs but IMHO we haven't been in the phase where it
was clear what should be there and converting relevant parts is just
matter of some manual work. I thought that time is better spent on
discussing and improving the actual architecture/design as that's what
takes time and thinking, not converting docs into format which is harder
to edit. I don't think that not being sgml prevented anybody from
reading it and commenting on it.

> On top of that, when various people provided review comments, they
> never resulted in an updated patch.  The original post was December
> 31st.  By January 10th, it had been reviewed by two people.  By
> January 17th, they'd both asked for an updated patch to be posted with
> a fix for a bug that had been uncovered in review.  More than three
> months later, there's still no new patch on that thread.

Yeah, sadly I didn't get to it in timely manner and by the time I did
get to it, it seemed like it's too late for 9.6. So I only sent URL to
git repo with fixes into the thread for anybody interested in reviewing
and moved on to help getting other people's patches in as that seemed
like more productive thing to do for 9.6 at that point. Since then, more
fundamental questions (like tighter integration into core as opposed to
contrib) appeared which make the above seem like a good decision (but it
also means no patch in the thread).

> That means somebody's got to submit something that
> looks like a committable patch and be prepared to do several rounds of
> timely revision of that patch as review comments arrive.  Andres is
> willing to review such a patch and I am, too.
>

That's good to hear.

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

On Mon, May  9, 2016 at 06:42:40PM +0200, Magnus Hagander wrote:
> That's exactly my thinking. If it's going to be *feature based* there is a
> fairly significant risk of this happening.
>
> I think the only reason to not do a 10.0 is if we want to stick to the "we
> switch when we break backwards compatibility". But that also means that if we
> succeed in not breaking backwards compatibility in a bad way (say we solve the
> problem of transparent page format upgrading, or just the logical replication
> based upgrading or whatever), then we never bump. Which *also* doesn't work
> very well.

If we are going to focus on update method _change_ rather than just
upgrade _breakage_, the inclusion of pg_logical in Postgres core would
be a reason to go to 10.0 because it allows zero-downtime upgrades.  I
think this would be larger upgrade-wise than anything in 9.6.

Currently users are using high-overhead trigger-based replication to
achieve zero-downtime upgrades, and using streaming replication with
pg_logical would be a game-changer.

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

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


Magnus Hagander reminded us:

> And we already have a version numbering scheme that confuses people :)

Exactly.  I think it is time for us to realize that our beloved "major.minor"
versioning is a failure, both at a marketing and a technical level. It's a
lofty idea, but causes way more harm than good in real life. People on
pgsql-hackers know that 9.1 and 9.5 are wildly different beasts. Clients?
They are running "Postgres 9". So I'm all in favor of doing away with
major and minor.

However, this may break some things that expect a triple number, so one
solution is to market it as Postgres 10, Postgres 11, etc. but keep the
minor number - which shall never be changed. Thus, our next releases
become:

10.0.0
11.0.0
12.0.0

And the revisions stay the same:

10.0.1
10.0.2
10.0.3
11.0.1
12.0.1
12.0.2

etc.

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

iEYEAREDAAYFAlc0mK4ACgkQvJuQZxSWSsjOOwCfTXel0ks/v6uBtysXdVjh824G
thgAnjq0mV+/H6GuuuBm6yPaY3144oHK
=eWiG
-----END PGP SIGNATURE-----

On Tue, May 10, 2016 at 05:21:24PM -0400, Bruce Momjian wrote:
> If we are going to focus on update method _change_ rather than just
> upgrade _breakage_, the inclusion of pg_logical in Postgres core would
> be a reason to go to 10.0 because it allows zero-downtime upgrades.  I
> think this would be larger upgrade-wise than anything in 9.6.
>
> Currently users are using high-overhead trigger-based replication to
> achieve zero-downtime upgrades, and using streaming replication with
> pg_logical would be a game-changer.

I would like to clarify something I said above.

In a master/slave setup with pg_logical, a major upgrade is _near_
zero-downtime, because you have to switch over all write transactions at
a single point in time when you promote the slave to master.  So you
have to either prevent new write transactions from going to the slave
while you wait for the master transactions to finish, or (more likely)
you have to terminate the write transactions on the master and then
promote the slave to master and allow everything to reconnect.

(In practice, you can't change a read/write server to read-only without
a restart, so effectively all old-master transactions have to be drained
at some point.)

Now, when using multi-master, you can cause new write transactions to
start on the new-major-upgraded master while you wait for the
old-major-version master to finish its transactions.

And, this doesn't require two servers.  You can run the master/slave or
multi-master on the same server, though this causes double the write
volume and disk space while it is set up.  If you set it up only for the
upgrade and during a slow activity period, that might be OK.

All this might have been obvious to people, but I only just now figured
it out.  I always thought multi-master was only useful for geo-locating
databases closer to users, but this graceful switch-over is another
advantage of multi-master.

Another issue is that I think BRR might have tarnished the community's
reputation for reliability.  I know everyone who downloaded BDR knows it
was an external project, but support is happening using the community
email lists, and the volume of problems reported, and the private
reliability complaints I have heard, make me concerned that people will
think BDR problems show that community Postgres also has
reliability/usability problems, which is bad.  I would hate to go
through the same thing with pg_logical.

I know BDR is complex, and I know that people got good support for it on
the community email lists, but we go through a lot of work to have the
server releases be rock solid, and I don't want to have that reputation
tarnished.

I know this all might be academic as the 9.6 beta1 release has been made,
but I wanted to point out the value of multi-master, and explain some of
my concerns more concretely.

--
  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/12/2016 07:53 AM, Greg Sabino Mullane wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> Magnus Hagander reminded us:
>
>> And we already have a version numbering scheme that confuses people :)
>
> Exactly.  I think it is time for us to realize that our beloved "major.minor"

Isn't it major.major.minor?

> versioning is a failure, both at a marketing and a technical level. It's a
> lofty idea, but causes way more harm than good in real life. People on
> pgsql-hackers know that 9.1 and 9.5 are wildly different beasts. Clients?
> They are running "Postgres 9". So I'm all in favor of doing away with
> major and minor.

Seems to work here without confusion:

https://docs.djangoproject.com/en/1.9/internals/release-process/

>
> However, this may break some things that expect a triple number, so one
> solution is to market it as Postgres 10, Postgres 11, etc. but keep the
> minor number - which shall never be changed. Thus, our next releases
> become:
>
> 10.0.0
> 11.0.0
> 12.0.0
>
> And the revisions stay the same:

And the never incrementing 0 is explained as?

I am not saying it is a bad idea just one that need explanation also,
which is true of all versioning schemes. The issue seems to be getting
the explanation out there, not the scheme.

>
> 10.0.1
> 10.0.2
> 10.0.3
> 11.0.1
> 12.0.1
> 12.0.2
>
> etc.
>
> - --
> Greg Sabino Mullane greg@turnstep.com
> End Point Corporation http://www.endpoint.com/
> PGP Key: 0x14964AC8 201605121051
> http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
> -----BEGIN PGP SIGNATURE-----
>
> iEYEAREDAAYFAlc0mK4ACgkQvJuQZxSWSsjOOwCfTXel0ks/v6uBtysXdVjh824G
> thgAnjq0mV+/H6GuuuBm6yPaY3144oHK
> =eWiG
> -----END PGP SIGNATURE-----
>
>
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com

On May 12, 2016 17:36, "Bruce Momjian" <bruce@momjian.us> wrote:
>
> On Tue, May 10, 2016 at 05:21:24PM -0400, Bruce Momjian wrote:
> > If we are going to focus on update method _change_ rather than just
> > upgrade _breakage_, the inclusion of pg_logical in Postgres core would
> > be a reason to go to 10.0 because it allows zero-downtime upgrades.  I
> > think this would be larger upgrade-wise than anything in 9.6.
> >
> > Currently users are using high-overhead trigger-based replication to
> > achieve zero-downtime upgrades, and using streaming replication with
> > pg_logical would be a game-changer.
>
> I would like to clarify something I said above.
>
> In a master/slave setup with pg_logical, a major upgrade is _near_
> zero-downtime, because you have to switch over all write transactions at
> a single point in time when you promote the slave to master.  So you
> have to either prevent new write transactions from going to the slave
> while you wait for the master transactions to finish, or (more likely)
> you have to terminate the write transactions on the master and then
> promote the slave to master and allow everything to reconnect.
>
> (In practice, you can't change a read/write server to read-only without
> a restart, so effectively all old-master transactions have to be drained
> at some point.)

You can make it closer to, or completely zero, if you combine it with pgbouncer in transaction pooling mode. There will be a performance hiccup, but it should work.

/Magnus

On Thu, May 12, 2016 at 10:53 AM, Greg Sabino Mullane <greg@turnstep.com> wrote:
> Exactly.  I think it is time for us to realize that our beloved "major.minor"
> versioning is a failure, both at a marketing and a technical level. It's a
> lofty idea, but causes way more harm than good in real life. People on
> pgsql-hackers know that 9.1 and 9.5 are wildly different beasts. Clients?
> They are running "Postgres 9". So I'm all in favor of doing away with
> major and minor.

I'm not.  I've had people be confused about that, but not often.
Maybe my clients are smarter than yours.  :-)

In my view, the principal advantage of the current system is that it
slow version number inflation.  Bumping the first version number every
year causes you to burn through ten numbers a decade rather than ~2,
and I find that appealing.

But of course that's a matter of opinion.

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

On Thu, May 12, 2016 at 05:43:28PM +0200, Magnus Hagander wrote:
>
> On May 12, 2016 17:36, "Bruce Momjian" <bruce@momjian.us> wrote:
> > In a master/slave setup with pg_logical, a major upgrade is _near_
> > zero-downtime, because you have to switch over all write transactions at
> > a single point in time when you promote the slave to master.  So you
> > have to either prevent new write transactions from going to the slave
> > while you wait for the master transactions to finish, or (more likely)
> > you have to terminate the write transactions on the master and then
> > promote the slave to master and allow everything to reconnect.
> >
> > (In practice, you can't change a read/write server to read-only without
> > a restart, so effectively all old-master transactions have to be drained
> > at some point.)
>
> You can make it closer to, or completely zero, if you combine it with pgbouncer
> in transaction pooling mode. There will be a performance hiccup, but it should
> work.

That is an interesting approach.  How many applications are prepared to
re-sent a transaction block based on the error returned by pgbouncer in
this case?

I am thinking our docs need a new section about reducing downtime during
switch-over, and using logical replication for major version upgrades.

--
  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/12/2016 07:53 AM, Greg Sabino Mullane wrote:
> Exactly.  I think it is time for us to realize that our beloved "major.minor"
> versioning is a failure, both at a marketing and a technical level. It's a
> lofty idea, but causes way more harm than good in real life. People on
> pgsql-hackers know that 9.1 and 9.5 are wildly different beasts. Clients?
> They are running "Postgres 9". So I'm all in favor of doing away with
> major and minor.

I can't say I agree.  I just think we should be faster to turn over the
major number.

If you'd asked me this a couple years ago, I probably would have agreed
with you.  However, a couple things have happened since then:

1) All the new DevOpsy stuff is *extremely* conservative in version
numbers.  For example, the new Docker release is 1.11, even though it is
the 2nd massive backwards-compat breakage release, which by all rights
ought to be 3.0.

2) Firefox's integer version numbering ... we're on 47 or something ...
has not turned out to be popular with users (note that I was partly
responsible for this idea, which seemed good at the time).

Overall, we have what I regard as a very minor problem, which is I'd
argue that we're about 50% too conservative in turning over the major
version number.  That doesn't require grand schemes to change how we
version.

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

On 12/05/16 18:09, Bruce Momjian wrote:
> On Thu, May 12, 2016 at 05:43:28PM +0200, Magnus Hagander wrote:
>>
>> On May 12, 2016 17:36, "Bruce Momjian" <bruce@momjian.us> wrote:
>>> In a master/slave setup with pg_logical, a major upgrade is _near_
>>> zero-downtime, because you have to switch over all write transactions at
>>> a single point in time when you promote the slave to master.  So you
>>> have to either prevent new write transactions from going to the slave
>>> while you wait for the master transactions to finish, or (more likely)
>>> you have to terminate the write transactions on the master and then
>>> promote the slave to master and allow everything to reconnect.
>>>
>>> (In practice, you can't change a read/write server to read-only without
>>> a restart, so effectively all old-master transactions have to be drained
>>> at some point.)
>>
>> You can make it closer to, or completely zero, if you combine it with pgbouncer
>> in transaction pooling mode. There will be a performance hiccup, but it should
>> work.
>
> That is an interesting approach.  How many applications are prepared to
> re-sent a transaction block based on the error returned by pgbouncer in
> this case?
>
> I am thinking our docs need a new section about reducing downtime during
> switch-over, and using logical replication for major version upgrades.
>

There is no error, in pgbouncer you can pause connections while waiting
for running transactions to finish, change the config for the databases
to point to the new server and then on resume and it will send the new
transactions to the new server. From application point of view this
looks like momentary latency increase, not as error. I did live demo of
this using continuously running pgbench during the upgrade/switchover on
several conferences.

The other point I want to make is that pglogical does already have
builtin simple conflict resolution (simple as in no custom resolution
methods, only the predefined last update wins, first update wins, always
apply remote data, always keep local data resolutions) so necessity of
disabling writes on the source database largely depends on the application.

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

Greg Sabino Mullane wrote:

> Magnus Hagander reminded us:
>
> > And we already have a version numbering scheme that confuses people :)
>
> Exactly.  I think it is time for us to realize that our beloved "major.minor"
> versioning is a failure, both at a marketing and a technical level. It's a
> lofty idea, but causes way more harm than good in real life. People on
> pgsql-hackers know that 9.1 and 9.5 are wildly different beasts. Clients?
> They are running "Postgres 9".

This is a good angle from which to consider versioning the next one as
10.0 instead of 9.6: are the differences since 9.0 significant?  Rather
than considering only the differences since 9.5.  In that light, I think
it's pretty clear that the accumulated feature set is huge, and that 9.6
is not like 9.0 in the slightest.  So even if 9.6 is not an enormous
advance over 9.5, this release has plenty of merit to become the first
one in the "Postgres 10" series for the next two ~ four releases.

> So I'm all in favor of doing away with major and minor.

I think we should keep the minor major but be more generous in upping
the major major.  I don't think we need to have a hard policy about it,
but about upping it two or three times a decade should be in the right
ballpark.

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

On 12-05-2016 13:09, Bruce Momjian wrote:
> That is an interesting approach.  How many applications are prepared to
> re-sent a transaction block based on the error returned by pgbouncer in
> this case?
>
FYI, pgBouncer does not error out transactions. While in PAUSE mode,
pgBouncer waits for the current transactions to finish and the new ones
are put in a wait queue. After the RESUME command, pgBouncer sends the
transaction in the wait queue. Of course, if your application has a
response timeout you will see cancellations.


--
   Euler Taveira                   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

On 12/05/16 19:00, Alvaro Herrera wrote:
> Greg Sabino Mullane wrote:
>
>> Magnus Hagander reminded us:
>>
>>> And we already have a version numbering scheme that confuses people :)
>>
>> Exactly.  I think it is time for us to realize that our beloved "major.minor"
>> versioning is a failure, both at a marketing and a technical level. It's a
>> lofty idea, but causes way more harm than good in real life. People on
>> pgsql-hackers know that 9.1 and 9.5 are wildly different beasts. Clients?
>> They are running "Postgres 9".
>
> This is a good angle from which to consider versioning the next one as
> 10.0 instead of 9.6: are the differences since 9.0 significant?  Rather
> than considering only the differences since 9.5.  In that light, I think
> it's pretty clear that the accumulated feature set is huge, and that 9.6
> is not like 9.0 in the slightest.  So even if 9.6 is not an enormous
> advance over 9.5, this release has plenty of merit to become the first
> one in the "Postgres 10" series for the next two ~ four releases.
>

+1 - this sums up my thoughts on the topic quite well.

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

On 05/12/2016 10:31 AM, Petr Jelinek wrote:
> On 12/05/16 19:00, Alvaro Herrera wrote:
>> Greg Sabino Mullane wrote:
>>
>>> Magnus Hagander reminded us:
>>>
>>>> And we already have a version numbering scheme that confuses people :)
>>>
>>> Exactly.  I think it is time for us to realize that our beloved
>>> "major.minor"
>>> versioning is a failure, both at a marketing and a technical level.
>>> It's a
>>> lofty idea, but causes way more harm than good in real life. People on
>>> pgsql-hackers know that 9.1 and 9.5 are wildly different beasts.
>>> Clients?
>>> They are running "Postgres 9".
>>
>> This is a good angle from which to consider versioning the next one as
>> 10.0 instead of 9.6: are the differences since 9.0 significant?  Rather
>> than considering only the differences since 9.5.  In that light, I think
>> it's pretty clear that the accumulated feature set is huge, and that 9.6
>> is not like 9.0 in the slightest.  So even if 9.6 is not an enormous
>> advance over 9.5, this release has plenty of merit to become the first
>> one in the "Postgres 10" series for the next two ~ four releases.
>>
>
> +1 - this sums up my thoughts on the topic quite well.

+1 - and mine

Joe


--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development

On 05/12/2016 08:54 AM, Robert Haas wrote:
> On Thu, May 12, 2016 at 10:53 AM, Greg Sabino Mullane <greg@turnstep.com> wrote:
>> Exactly.  I think it is time for us to realize that our beloved "major.minor"
>> versioning is a failure, both at a marketing and a technical level. It's a
>> lofty idea, but causes way more harm than good in real life. People on
>> pgsql-hackers know that 9.1 and 9.5 are wildly different beasts. Clients?
>> They are running "Postgres 9". So I'm all in favor of doing away with
>> major and minor.
>
> I'm not.  I've had people be confused about that, but not often.
> Maybe my clients are smarter than yours.  :-)

I have to say that I don't run into it all that much either. Yes,
sometimes but it is rare and the clients that don't understand it after
a 30 second explanation aren't going to understand why 9 is more
important than 10 without explanation either.

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.

Magnus Hagander wrote:
> On Thu, May 12, 2016 at 7:00 PM, Alvaro Herrera <alvherre@2ndquadrant.com>
> wrote:

> > I think we should keep the minor major but be more generous in upping
> > the major major.  I don't think we need to have a hard policy about it,
> > but about upping it two or three times a decade should be in the right
> > ballpark.
>
> Is everybody using the same term her?
>
> Per our website, which is our public face, "major version" means 9.4, 9.5
> etc. Minor versions are 9.5.2, 9.5.3. the "9.x" has no name.
>
> Are people really talking about getting rid of major/minor versions, or
> just changing the format of the major version number?
>
> Let's make sure we all use the same terms...

Sorry.  I used "major major" to refer to the 9 and "minor major" to
refer to the 5 in "9.5".  Combining both, "9.5" would be the "major".

Greg is suggesting to keep everything intact but to never again
increment the "minor major", i.e. all versions be X.0 (10.0, 11.0, 12.0
would be the 2016, 2017, 2018 releases, roughly).  I disagree with this
idea, because the .0 becames useless noise.

Others have suggested to remove the "minor major" altogether and just
keep the major major, i.e. 10 would be the 2016 release, 11 would be the
2017 release, 12 would be the 2018 release.  I don't like this very much
because it's disruptive and confusing: each bugfix release would become
11.1 12.2 etc which would be confused with a regular major release by
people used to our current versioning scheme.


My suggestion is to keep everything as today, but increase the
"major major" more frequently, and to continue to use the "minor major"
as today, i.e. increase yearly and reset to 0 when the major major is
increased.

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

On 13/05/16 02:53, Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
> Magnus Hagander reminded us:
>
>> And we already have a version numbering scheme that confuses people :)
> Exactly.  I think it is time for us to realize that our beloved "major.minor"
> versioning is a failure, both at a marketing and a technical level. It's a
> lofty idea, but causes way more harm than good in real life. People on
> pgsql-hackers know that 9.1 and 9.5 are wildly different beasts. Clients?
> They are running "Postgres 9". So I'm all in favor of doing away with
> major and minor.

[...]

Please don't go that way, the inflation of numbers like Firefox has, the
numbers then have even less meaning.

Stop dumbing things down!!!  Help educate people, rather than become yet
another Mushroom Farmer...

Better would be a prominent notice of what the versioning scheme is all
about, and link to http://semver.org.


Cheers,
Gavin

On 13/05/16 02:53, Greg Sabino Mullane wrote:

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


Magnus Hagander reminded us:

And we already have a version numbering scheme that confuses people :)

Exactly.  I think it is time for us to realize that our beloved "major.minor"
versioning is a failure, both at a marketing and a technical level. It's a
lofty idea, but causes way more harm than good in real life. People on
pgsql-hackers know that 9.1 and 9.5 are wildly different beasts. Clients?
They are running "Postgres 9". So I'm all in favor of doing away with
major and minor.

[...]

Please don't go that way, the inflation of numbers like Firefox has, the numbers then have even less meaning.

Stop dumbing things down!!!  Help educate people, rather than become yet another Mushroom Farmer...

Better would be a prominent notice of what the versioning scheme is all about, and link to http://semver.org.

On 2016-05-12 8:54 AM, Robert Haas wrote:
> In my view, the principal advantage of the current system is that it
> slow version number inflation.  Bumping the first version number every
> year causes you to burn through ten numbers a decade rather than ~2,
> and I find that appealing.
>
> But of course that's a matter of opinion.

This implies that numbers are a scarce resource, which they are not, we have an
infinite number of them.  Also mind that even going this way, we aren't going to
get to the end of the 2-digit major versions for a century. -- Darren Duncan

On 13/05/16 18:55, Darren Duncan wrote:
> On 2016-05-12 8:54 AM, Robert Haas wrote:
>> In my view, the principal advantage of the current system is that it
>> slow version number inflation.  Bumping the first version number every
>> year causes you to burn through ten numbers a decade rather than ~2,
>> and I find that appealing.
>>
>> But of course that's a matter of opinion.
>
> This implies that numbers are a scarce resource, which they are not,
> we have an infinite number of them.  Also mind that even going this
> way, we aren't going to get to the end of the 2-digit major versions
> for a century. -- Darren Duncan
>
>
>
How about we initiate hyper inflation and call the next version of pg
1000, so it appears to be 100 times better than MySQL which is only on
version 10 - we can always give pg a version number greater than
whatever the MySQL crowd assigns there latest version - after all 'we
have an infinite number of them'!

Simply because there are more numbers than we need, does NOT mean that
we SHOULD to go for larger numbers!

I accept that the differences between pg 9.0 & 9.6 are greater than
between pg 8.0 & 9,0 - so renaming the current 9.6 as 10, or the next
(9.7) as 10 - seems quite reasonable to me.

I would not object to having a version 9.42 in a few years - though not
for more than a few seconds!   :-)

> so renaming the current 9.6 as 10, or the next (9.7) as 10 - seems quite reasonable to me.

Hi,

is renaming the current 9.6 as 10 still an option, now that 9.6 beta 1 has been released?

Bye,
Chris.

On Fri, May 13, 2016 at 8:39 PM, Chris Mair <chris@1006.org> wrote:
> is renaming the current 9.6 as 10 still an option, now that 9.6 beta 1 has
> been released?

Point of history: there has been 8.5 alpha 1, 2 and 3 before it was
renamed to 9.0.

(No opinion on the debate to offer to be honest)
--
Michael

On 13-05-2016 09:22, Michael Paquier wrote:
> On Fri, May 13, 2016 at 8:39 PM, Chris Mair <chris@1006.org> wrote:
>> is renaming the current 9.6 as 10 still an option, now that 9.6 beta 1 has
>> been released?
>
> Point of history: there has been 8.5 alpha 1, 2 and 3 before it was
> renamed to 9.0.
>
Alpha is different from beta which means that discussion started earlier
than this one (in terms of release date) -- 13 months or so earlier x 4
months (September). It seems strange to rename a beta version because
people use (for test purposes) more beta than alpha. Even at that time
(8.5 alpha) I faced a lot of confusion (2 version in parallel?). Let's
not do it again. Consistency is a good thing. Instead, let's reach a
consensus for the next version much earlier than this time. In my
opinion, when we close the last CF, we have more or less the release
roadmap and can argue more precisely.


--
   Euler Taveira                   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

On 14/05/16 00:56, Euler Taveira wrote:
> On 13-05-2016 09:22, Michael Paquier wrote:
>> On Fri, May 13, 2016 at 8:39 PM, Chris Mair <chris@1006.org> wrote:
>>> is renaming the current 9.6 as 10 still an option, now that 9.6 beta 1 has
>>> been released?
>> Point of history: there has been 8.5 alpha 1, 2 and 3 before it was
>> renamed to 9.0.
>>
> Alpha is different from beta which means that discussion started earlier
> than this one (in terms of release date) -- 13 months or so earlier x 4
> months (September). It seems strange to rename a beta version because
> people use (for test purposes) more beta than alpha. Even at that time
> (8.5 alpha) I faced a lot of confusion (2 version in parallel?). Let's
> not do it again. Consistency is a good thing. Instead, let's reach a
> consensus for the next version much earlier than this time. In my
> opinion, when we close the last CF, we have more or less the release
> roadmap and can argue more precisely.
>
>
I suspect 9.6 beta will go out as 9.6, but '9.7' will be released as
10.0 - based on my reading of this thread.

I think that most people are agreed that more than enough features have
been added to the 9.x series to warrant making it 10, but not enough
warning for people to be happy, though a majority of people would either
accept (or like) the 9.7 ==> 10.0 change.  Plus it would give time for
people to gear up mentally to make '9.7' a suitable '10.0' release and
allow potentially upgrade breaking changes (which would need plenty of
time for adequate discussion).


Cheers,
Gavin

On 2016-05-13 3:07 AM, Gavin Flower wrote:
> On 13/05/16 18:55, Darren Duncan wrote:
>> On 2016-05-12 8:54 AM, Robert Haas wrote:
>>> In my view, the principal advantage of the current system is that it
>>> slow version number inflation.  Bumping the first version number every
>>> year causes you to burn through ten numbers a decade rather than ~2,
>>> and I find that appealing.
>>>
>>> But of course that's a matter of opinion.
>>
>> This implies that numbers are a scarce resource, which they are not, we have
>> an infinite number of them.  Also mind that even going this way, we aren't
>> going to get to the end of the 2-digit major versions for a century. -- Darren
>> Duncan
>>
> How about we initiate hyper inflation and call the next version of pg 1000, so
> it appears to be 100 times better than MySQL which is only on version 10 - we
> can always give pg a version number greater than whatever the MySQL crowd
> assigns there latest version - after all 'we have an infinite number of them'!
>
> Simply because there are more numbers than we need, does NOT mean that we SHOULD
> to go for larger numbers!

You missed my point.  Lots of people try to increase numbers as slowly as
possible because they're afraid they're going to run out like they only have a
small fixed number to work with, eg they think they only have 0-9.  I don't want
hyper inflation and I also think huge numbers look bad.  My point is we don't
need to be stingy with increasing the number, and increasing the first integer
with each major annual release is fine. -- Darren Duncan

El 13/05/16 a las 08:39, Chris Mair escribió:
>> so renaming the current 9.6 as 10, or the next (9.7) as 10 - seems
>> quite reasonable to me.
>
> Hi,
>
> is renaming the current 9.6 as 10 still an option, now that 9.6 beta 1
> has been released?

I hope not.

Developers are already applying changes to their tools which check on
postgres version is running to apply one code or another (or to use
options specific to 9.6).

Not a burden, but I'd prefer to concentrate on other tasks.

Regards,

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

On Thu, May 12, 2016 at 02:07:04PM -0300, Euler Taveira wrote:
> On 12-05-2016 13:09, Bruce Momjian wrote:
> > That is an interesting approach.  How many applications are prepared to
> > re-sent a transaction block based on the error returned by pgbouncer in
> > this case?
> >
> FYI, pgBouncer does not error out transactions. While in PAUSE mode,
> pgBouncer waits for the current transactions to finish and the new ones
> are put in a wait queue. After the RESUME command, pgBouncer sends the
> transaction in the wait queue. Of course, if your application has a
> response timeout you will see cancellations.

Oh, that seems useful.

--
  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 01:41 PM, Bruce Momjian wrote:
> On Thu, May 12, 2016 at 02:07:04PM -0300, Euler Taveira wrote:
>> On 12-05-2016 13:09, Bruce Momjian wrote:
>>> That is an interesting approach.  How many applications are prepared to
>>> re-sent a transaction block based on the error returned by pgbouncer in
>>> this case?
>>>
>> FYI, pgBouncer does not error out transactions. While in PAUSE mode,
>> pgBouncer waits for the current transactions to finish and the new ones
>> are put in a wait queue. After the RESUME command, pgBouncer sends the
>> transaction in the wait queue. Of course, if your application has a
>> response timeout you will see cancellations.
>
> Oh, that seems useful.
>

The missing feature is that you can never forceably terminate the
connections to the old master without restarting pgbouncer.  And if you
just shut down the old database server, with some clients still
connected, pgbouncer goes into "error mode" and starts denying some
legit connections.  So there's still work to be done here.

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

On 13-05-2016 17:45, Josh berkus wrote:
> The missing feature is that you can never forceably terminate the
> connections to the old master without restarting pgbouncer.  And if you
> just shut down the old database server, with some clients still
> connected, pgbouncer goes into "error mode" and starts denying some
> legit connections.  So there's still work to be done here.
>
Could you open an issue [1]?


[1] https://github.com/pgbouncer/pgbouncer/issues


--
   Euler Taveira                   Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

Following up...

It appears from today's PgCon meeting that the majority of core developers agree
with my simplified proposal, just having MAJOR.PATCH version numbers, and that
the plan is to implement that, pending packager/etc feedback.

https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Meeting#Poll_on_Version_Numbering

-- Darren Duncan

On 2016-05-09 6:06 PM, Darren Duncan wrote:
> So, I have a simplified proposal, inspired by David G's comments.
>
> Get rid of the middle number entirely.  Increment the first number for every
> major version, use the second number to indicate patches.
>
> So then the major releases from now on would be 10.0, 11.0, 12.0 etc.
>
> Then this whole thread is bike shedding we can avoid.  No need to justify 9.x vs
> 10 etc which is heavily arbitrary.
>
> EVERY major release is quite significant, so just give them all a new high
> number, the end?
>
> Would this satisfy everyone?
>
> As such, assuming this proposal is adopted, I firmly support 10.0 for the next
> major.
>
> Whereas, if this proposal is not adopted, I see no strong reason to pick a
> winner between 9.6 and 10.0.
>
> -- Darren Duncan
>
> On 2016-05-09 5:44 PM, David G. Johnston wrote:
>> On Mon, May 9, 2016 at 5:19 PM, Darren Duncan <darren@darrenduncan.net>wrote:
>>
>>     On 2016-05-09 3:24 PM, Josh berkus wrote:
>>
>>         On 05/09/2016 03:18 PM, Darren Duncan wrote:
>>
>>             Loosely speaking, have at least MAJOR.MINOR.PATCH.MATURITY
>> components,
>>             optionally more.  MAJOR must be increased when a
>> backwards-compatibility
>>             break is made of any kind (such as removing a feature), otherwise
>> MINOR
>>             must be increased for any forwards-compatibility break (such as
>> adding a
>>             feature), otherwise PATCH must be increased for changes that
>> shouldn't
>>             break any kind of compatibility, except for fixing bugs or security
>>             holes where the old behavior was not being relied on for any working
>>             uses.  MATURITY means eg alpha/beta/rc/production etc.
>>
>>         That seems like that would be an argument against 10.0?  Since we didn't
>>         break backwards compat?
>>
>>     To be clear, I am talking about backwards compatibility in a holistic sense,
>>     both API *and* database cluster file format.
>>
>>     0.  Start with the context of a standalone (not replicated) Postgres 9.5
>>     database cluster D1 and Postgres 9.5 binaries P1 and an application A1 using
>>     those.  A1 also includes the set of SQL/etc queries made manually by users.
>>
>>     1.  Shutdown the Postgres servers P1, install new Postgres 9.6 binaries P2,
>>     start Postgres servers P2, this all without making any changes to D1 or A1
>>     which includes not running pg_upgrade etc.
>>
>>     2.  Use A1 for awhile without making any changes to it.
>>
>>     3.  Shutdown the Postgres 9.6 servers P2, reinstall or use the previous
>>     Postgres 9.5 binaries P1, start Postgres servers P1.
>>
>>     If despite switching to 9.6 and then back to 9.5 without making any changes
>>     to the application, everything just keeps working, then 9.6 is
>>     backwards-compatible with 9.5 in the holistic sense.
>>
>>     When using 9.6 in the same way as 9.5 was used breaks the ability to use a
>>     database cluster as is with 9.5, backwards compatibility is broken.
>>
>> ​Default maturity is "production" - we introduce beta, etc... at the end of a
>> release cycle.
>>
>> I'm highly doubtful we could go an entire year without introducing a backward
>> incompatibility - and to date we've never attempted to avoid doing so.  Thus
>> what this proposal boils down to is:
>>
>> Major.Patch[.Maturity]
>>
>> Minor would never be incremented and would constitute harmful noise (it would
>> imply potential that doesn't practically exist) if specified explicitly
>
> I agree with you.  Having the separate MINOR is more of a project-agnostic mold
> and for Postgres doesn't really help when the rules would make incrementing
> MAJOR what is done for nearly every break.  Having MINOR works much better for
> say SQLite who haven't had a backwards-compatibility break in over 13 years.
>
>> IOW - We should just go to 10.0 in lieu of a 9.7 release, all then bug-fix
>> releases increment 10.1, 10.2, 10.3, etc..., and two years from now we release
>> 11.0
>
> I agree/believe that if Postgres went with a semantic versioning scheme, it
> should start off with a MAJOR increase to more clearly mark when the regime
> change happened, as you say.
>
> Or even if we essentially kept things as they are now, getting rid of the middle
> number is helpful.  Just increment the first number for every major release and
> the second number for bug fixes.  Then we can avoid all the bikeshedding of this
> thread.
>
>> Semantic versioning has become more prevalent as more and more project have
>> either weekly/monthly cycles OR indefinite cycles where the increment will
>> depend on what just got patched at any given point in time.  PostgreSQL doesn't
>> fit into either of those molds so 4+ semantic levels just doesn't make sense.
>
> I agree.
>
>> ​I'm sticking to my opinion that because of our present numbering scheme and our
>> 5-year support cycle we should increment major accordingly to those project
>> policies and should consider aligning advocacy on that time pulse so certain
>> aspects are emphasized during years 0,1,2,3,4 of the release cycle.  But, then
>> again, I'm not close enough to this to say that what we have now is even broken
>> and warrants changing.  All I have is an unproven setup based upon logic and
>> symmetry with only minimal practical experience in advocacy.​
>
> -- Darren Duncan
>
>
>

On 18 May 2016, at 05:35, Darren Duncan <darren@darrenduncan.net> wrote:
> Following up...
>
> It appears from today's PgCon meeting that the majority of core developers agree with my simplified proposal, just
havingMAJOR.PATCH version numbers, and that the plan is to implement that, pending packager/etc feedback. 
>
> https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Meeting#Poll_on_Version_Numbering

Looking at the entry there in the wiki, it says:

  "Simon called for a vote on whether the next release will be 10.0. There was
   already consensus that the next release is 10.0."

For clarity, does that mean this release coming soon is 10.0, or the release
after that - sometime in 2017(?) - is 10.0? :)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

On 18/05/16 14:51, Justin Clift wrote:
> On 18 May 2016, at 05:35, Darren Duncan <darren@darrenduncan.net> wrote:
>> Following up...
>>
>> It appears from today's PgCon meeting that the majority of core developers agree with my simplified proposal, just
havingMAJOR.PATCH version numbers, and that the plan is to implement that, pending packager/etc feedback. 
>>
>> https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Meeting#Poll_on_Version_Numbering
>
> Looking at the entry there in the wiki, it says:
>
>   "Simon called for a vote on whether the next release will be 10.0. There was
>    already consensus that the next release is 10.0."
>
> For clarity, does that mean this release coming soon is 10.0, or the release
> after that - sometime in 2017(?) - is 10.0? :)

9.6 will be 9.6, the next version will be 10.0 (instead of 9.7).
--
Vik Fearing                                          +33 6 46 75 15 36
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support

El 18/05/16 a las 09:56, Vik Fearing escribió:
> On 18/05/16 14:51, Justin Clift wrote:
>> On 18 May 2016, at 05:35, Darren Duncan <darren@darrenduncan.net> wrote:
>>> Following up...
>>>
>>> It appears from today's PgCon meeting that the majority of core developers agree with my simplified proposal, just
havingMAJOR.PATCH version numbers, and that the plan is to implement that, pending packager/etc feedback. 
>>>
>>> https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Meeting#Poll_on_Version_Numbering
>>
>> Looking at the entry there in the wiki, it says:
>>
>>   "Simon called for a vote on whether the next release will be 10.0. There was
>>    already consensus that the next release is 10.0."
>>
>> For clarity, does that mean this release coming soon is 10.0, or the release
>> after that - sometime in 2017(?) - is 10.0? :)
>
> 9.6 will be 9.6, the next version will be 10.0 (instead of 9.7).

I think that 9.7 will be 10, and not 10.0.

Moving to major.minor versioning.

Regards,

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

El 18/05/16 a las 01:35, Darren Duncan escribió:
> Following up...
>
> It appears from today's PgCon meeting that the majority of core
> developers agree with my simplified proposal, just having MAJOR.PATCH
> version numbers, and that the plan is to implement that, pending
> packager/etc feedback.
>
> https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Meeting#Poll_on_Version_Numbering

Looking at possible issues regarding packaging and new versioning format
last weekend, I couldn't find any reason for the versioning change to
break packaging on PGDG debs and rpms.

Anyway, lets wait on the actual packagers to state their points of view. ;)

Regards,

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

On 05/18/2016 09:07 AM, Martín Marqués wrote:
> El 18/05/16 a las 09:56, Vik Fearing escribió:

>> 9.6 will be 9.6, the next version will be 10.0 (instead of 9.7).

This is correct.

> I think that 9.7 will be 10, and not 10.0.
>
> Moving to major.minor versioning.

This is a strong possibility, but is not yet decided.

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

On 05/18/2016 06:33 AM, Josh berkus wrote:
> On 05/18/2016 09:07 AM, Martín Marqués wrote:
>> El 18/05/16 a las 09:56, Vik Fearing escribió:
>
>>> 9.6 will be 9.6, the next version will be 10.0 (instead of 9.7).
>
> This is correct.
>
>> I think that 9.7 will be 10, and not 10.0.
>>
>> Moving to major.minor versioning.
>
> This is a strong possibility, but is not yet decided.
>

A community vote:

-1

--
Adrian Klaver
adrian.klaver@aklaver.com

On 05/18/2016 06:33 AM, Josh berkus wrote:

On 05/18/2016 09:07 AM, Martín Marqués wrote:

El 18/05/16 a las 09:56, Vik Fearing escribió:

9.6 will be 9.6, the next version will be 10.0 (instead of 9.7).

This is correct.

I think that 9.7 will be 10, and not 10.0.

Moving to major.minor versioning.

This is a strong possibility, but is not yet decided.

A community vote:

-1

On 05/18/2016 06:46 AM, Dave Page wrote:
>
>
> On Wednesday, May 18, 2016, Adrian Klaver <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> wrote:
>
>     On 05/18/2016 06:33 AM, Josh berkus wrote:
>
>         On 05/18/2016 09:07 AM, Martín Marqués wrote:
>
>             El 18/05/16 a las 09:56, Vik Fearing escribió:
>
>
>                 9.6 will be 9.6, the next version will be 10.0 (instead
>                 of 9.7).
>
>
>         This is correct.
>
>             I think that 9.7 will be 10, and not 10.0.
>
>             Moving to major.minor versioning.
>
>
>         This is a strong possibility, but is not yet decided.
>
>
>     A community vote:
>
>     -1
>
>
> For what reason?

It is a solution in search of a problem and has more to do with
vanity(number envy) then anything. The project has enough legitimate
issues on its table without chasing after made up issues.

>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


--
Adrian Klaver
adrian.klaver@aklaver.com

On 05/18/2016 06:46 AM, Dave Page wrote:
>
>
> On Wednesday, May 18, 2016, Adrian Klaver <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> wrote:

>         This is a strong possibility, but is not yet decided.
>
>
>     A community vote:
>
>     -1
>
>
> For what reason?

 From my perspective we are fixing something that isn't broken. Every
few years somebody gets an ingrown toenail about our versioning (I have
done it in the past too) and we go round and round. It is just this time
the hackers justifiably tired of dealing with the argument so they are
going to change it.

If it were my decision: Folks, please move on to an argument that is
productive for the community, thanks!

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.

Hi,

Am Mittwoch, den 18.05.2016, 06:51 -0700 schrieb Joshua D. Drake:
> On 05/18/2016 06:46 AM, Dave Page wrote:
> > On Wednesday, May 18, 2016, Adrian Klaver <adrian.klaver@aklaver.com
> > <mailto:adrian.klaver@aklaver.com>> wrote:
>
> >         This is a strong possibility, but is not yet decided.
> >
> >
> >     A community vote:
> >
> >     -1
> >
> >
> > For what reason?
>
>  From my perspective we are fixing something that isn't broken.

There is no clear consensus why some major versions  should be more
major than others, and breaking compatibility is off the table as reason
it seems.

So moving to just a major version is fixing the "I am on Postgres 9"
issue, which was broken IMO, and it also fixes the 50+ mail threads
every release about "this should be the next .0" which were/are draining
the community as well.

It's been decided to investigate the new version scheme at the Developer
Meeting after extensive discussions so I wonder why we need to kep
argueing about the bikeshed now.


Michael

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

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

On 05/18/2016 06:46 AM, Dave Page wrote:

On Wednesday, May 18, 2016, Adrian Klaver <adrian.klaver@aklaver.com
<mailto:adrian.klaver@aklaver.com>> wrote:

    On 05/18/2016 06:33 AM, Josh berkus wrote:

        On 05/18/2016 09:07 AM, Martín Marqués wrote:

            El 18/05/16 a las 09:56, Vik Fearing escribió:


                9.6 will be 9.6, the next version will be 10.0 (instead
                of 9.7).


        This is correct.

            I think that 9.7 will be 10, and not 10.0.

            Moving to major.minor versioning.


        This is a strong possibility, but is not yet decided.


    A community vote:

    -1


For what reason?

It is a solution in search of a problem and has more to do with vanity(number envy) then anything. The project has enough legitimate issues on its table without chasing after made up issues.

On 05/18/2016 09:57 AM, Michael Banck wrote:
> There is no clear consensus why some major versions  should be more
> major than others, and breaking compatibility is off the table as reason
> it seems.

Well, the problem with the "breakage" approach is that then we just
argue about "how much breakage is enough to justify a major-major"?  It
changes the content of the annual argument, without making it go away.

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

On 05/18/2016 07:04 AM, Dave Page wrote:
>
>
> On Wednesday, May 18, 2016, Adrian Klaver <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> wrote:
>
>     On 05/18/2016 06:46 AM, Dave Page wrote:
>
>
>
>         On Wednesday, May 18, 2016, Adrian Klaver <adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>> wrote:
>
>             On 05/18/2016 06:33 AM, Josh berkus wrote:
>
>                 On 05/18/2016 09:07 AM, Martín Marqués wrote:
>
>                     El 18/05/16 a las 09:56, Vik Fearing escribió:
>
>
>                         9.6 will be 9.6, the next version will be 10.0
>         (instead
>                         of 9.7).
>
>
>                 This is correct.
>
>                     I think that 9.7 will be 10, and not 10.0.
>
>                     Moving to major.minor versioning.
>
>
>                 This is a strong possibility, but is not yet decided.
>
>
>             A community vote:
>
>             -1
>
>
>         For what reason?
>
>
>     It is a solution in search of a problem and has more to do with
>     vanity(number envy) then anything. The project has enough legitimate
>     issues on its table without chasing after made up issues.
>
>
> It is a solution to the issue that every couple of years we waste a ton
> of man-hours on discussions like this. With a move to a 2 digit number,
> that stops.

No, it just changes the argument to something new. For instance if
compatibility is ever broken, how is that communicated. In the meantime
the 'marketing' folks in the crowd will be going on about how to make
this major version appear different from the last major version. This
argument will keep going on if for no other reason then that the version
serve two purposes, PR and technical merit. Reconciling those purposes
is always going to be a discussion.

>
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>


--
Adrian Klaver
adrian.klaver@aklaver.com

Adrian,

You've made your opinion on this clear.  At this point, further
arguments aren't going to change anything.

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