Re: 10.0

> On May 13, 2016, at 5:49 PM, Josh berkus <josh@agliodbs.com> wrote:
>
> On 05/13/2016 05:22 PM, Mark Dilger wrote:
>>>>>> Any project that starts inflating its numbering scheme sends a message to
>>>>>> users of the form, "hey, we've just been taken over by marketing people, and
>>>>>> software quality will go down from now on."
>>>>
>>>> I don't think this is about version number inflation, but actually more
>>>> the opposite.  What you're calling the major number is really a marketing
>>>> number.  There is not a technical distinction between major releases where
>>>> we choose to bump the first number and those where we choose to bump the
>>>> second.  It's all about marketing.  So to me, merging those numbers would
>>>> be an anti-marketing move.  I think it's a good move: it would be more
>>>> honest and transparent about what the numbers mean, not less so.
>> I find your argument persuasive if there is no possibility of ever needing
>> a major number to bump.  But if anything like what I described above could
>> someday happen, it seems the major.minor.micro format would come in
>> handy.  Perhaps the problem (from my perspective) is that the major number
>> has been used for purely marketing purposes in the past, and I've tried to
>> avert my eyes to that.  But going forward, my vote (worth less than half a
>> cent I'm sure) is to stop using it for marketing reasons.
>
> Per a long discussion on -advocacy, nobody has any specific plans to do
> substantial breakage of backwards compatibility.  Theoretically we might
> someday want to change the on-disk format, but nobody has plans to do so
> in the immediate future.  How long should we hold out for that?  Until 9.27?
>
> And I don't find dropping the "money" type to be substantial breakage.

If minor number bumps mean, "dump and restore is necessary, but client
programs are guaranteed to still work", then dropping the "money" type
is a different kind of action.  Maybe you don't think it matters much, but
for somebody who is using it in a client application, that matters.  Likewise,
somebody who has a struct in a client program that expects Oid to fit into
32 bits *needs* to go through their client programs if Oid ever gets changed
to 64 bit.  (Pigs will probably fly first, but just for instance.)

I'm not advocating any of these changes today.  I just think they are different
kinds of changes from adding new functions while leaving all old functions
in tact.  As cool as parallel query is (and I'd happily buy Robert or Amit a
beer) it doesn't break any functionality in client applications that ignore it,
so far as I can see.  Using parallel query as a motivation for increasing the
major number stems from a marketing instinct, not from sound engineering
practices.

Now that I've said that, I'll sit back and wait for the REL10_0_DEVEL
branch to appear in the repo.

mark