Re: 9.6 -> 10.0

On Mon, May 9, 2016 at 6:16 PM, Josh berkus <josh(at)agliodbs(dot)com> wrote:

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

Along with multi-standby syncrep, which has been on the list since we first
got replication. And improvements to postgres_fdw which have obviously
"only" been on the list since postgres_fdw was created. The vacuum changes
are probably not very marketable, but they are huge for some of the users.

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

I think it's dangerous to bet on something like that. While I certainly
hope and think it will be, we certainly don't 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?
> >
> > 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 :)

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

So if we do this, we can jump them when 11.0 is out :P

And yes. It is a problem that people thing that 9.x is all the same. But
putting *even more* into the 9.0 train doesn't help that problem.

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

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.

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

As am I. (And yes, if anybody is tallying, that means I changed my original
vote -- this is because a lot more got in in the last month and a half than
I expected)

//Magnus