Re: 10.0 - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: 10.0
Date
Msg-id CAKFQuwbN6iyg-UGq+zOh9bxQ8XZ29Px4B+H3KPHzAk6HCpPbrg@mail.gmail.com
Whole thread Raw
In response to Re: 10.0  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: 10.0
List pgsql-hackers
On Mon, Jun 20, 2016 at 5:08 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jun 20, 2016 at 4:53 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> Or we could adopt the very reasonable and practical policy of:
>
> The current versioning scheme isn't broke, so we aren't going to fix it.

Yeah, no kidding.  We had a perfectly good consensus to keep this at
9.6 on pgsql-advocacy, and then later we had a revised consensus to
retitle it to 10.0,

​If -advocacy had changed their mind before beta1 was tagged this may have played out a bit differently...maybe.​  In any case 9.6 was a foregone conclusion given -advocacy's timeline and because of its independence from -hackers (Tom, the tagger, specifically).

but as soon as the discussion came over to
pgsql-hackers nothing would do but that we relitigate the whole thing
ignoring the previous discussion because it wasn't on pgsql-hackers.
Why -hackers is the right place to decide on the marketing version
number rather than -advocacy went unexplained, of course.

​I had the same thought.  Yet no one even tried to move the discussion back there.  And at this point PGCon was so close that I personally figured it would be discussed.  It was, and an announcement was made that a decision was reached.  No one voiced an objection​ so those not at PGCon (or at I) figured for better or worse we're going to version 10 (expected) and to address the expressed desire reduce the public confusion surrounding our major-major-minor version scheme we would instead switch to a more traditional major-minor scheme (acceptable).

  Now we have
a new consensus, at least the third if not the fourth or fifth, about
what to do on this topic, and since Tom likes this outcome better he'd
like to stop discussion right here. 

​This portion of the thread was mostly a technical concern - how do we display the version in human-readable and machine-readable formats.  I'd agree with your earlier idea that if you really want to open up the decision between 10.n.x and 10.x ​start a new thread on -advocacy.  Tally up those at PGCon as a starting point and lets other toss in their lot from there.  At this point I'm only seeing rehashing of the same arguments.  Let other people make their, informed or otherwise, opinions known if you feel that the group at PGCon is not a fair sampling.
 
A two-part version numbering
scheme may or may not be for the best, but the idea that we're making
that decision in any principled way, or that the consensus on this new
system is any more valid than any of the previous consensus, doesn't
ring true to me.  The idea that this discussion is not fixing any real
problem, though -- that rings true.


You've hijack the meaning of "this here.  Most of "this" thread ended up explaining the difference between "version()" and current_setting('server_version_num").  That needs to be addressed unless we revert back to status-quo.  That isn't this thread, though.  This thread assumes we are going to 10.0 and semantically losing the middle digit.

I'd find it odd to argue against 10.0 on the basis that we'd be displaying 10.0.x in the output of version().  That seems like such a inconsequential detail in the larger scheme of things.  Either you accept 10.0 and we pick a human readable output or you don't and the decision doesn't come into play.  I'm happy with how things are (+0.5 for we should output 10.0.x for version()) so I'm stopping here.

David J.

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: 10.0
Next
From: Robert Haas
Date:
Subject: Re: parallel.c is not marked as test covered