Re: 9.6 -> 10.0 - Mailing list pgsql-advocacy
| From | Magnus Hagander |
|---|---|
| Subject | Re: 9.6 -> 10.0 |
| Date | |
| Msg-id | CABUevEwQs1JPUavwwudr-5ofL9n63DYrZDe5wbE4txpzZm7XtQ@mail.gmail.com Whole thread Raw |
| In response to | Re: 9.6 -> 10.0 (Josh berkus <josh@agliodbs.com>) |
| Responses |
Re: 9.6 -> 10.0
Re: 9.6 -> 10.0 Re: 9.6 -> 10.0 New versioning scheme |
| List | pgsql-advocacy |
On Mon, May 9, 2016 at 6:16 PM, Josh berkus <josh@agliodbs.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
pgsql-advocacy by date: