Re: 10.0

> On May 13, 2016, at 5:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Mark Dilger <hornschnorter@gmail.com> writes:
>> A major number change should indicate that something even bigger than on-disk
>> compatibility has changed, such as a change that precludes even a dump and
>> restore from working, or that breaks network communication protocols, etc.
>
> If that were the standard, we'd never have bumped the major version at
> all, and would still be on 4.something (or whatever Berkeley was using
> when they tossed it over the wall; I'm not too clear on whether there was
> ever a 5.x release).  I can't imagine that we'd ever intentionally break
> dump/restore compatibility.  While we have changed the network protocol,
> and likely will again, we kept on supporting the old protocol alongside,
> and almost certainly would do so again.  There are too many compatibility
> constraints that we have to meet in order to be a usable database at all,
> so we're never going to just blow it up and start over.

Well, those are just examples.  Other candidate examples would be dropping
datatypes such as 'money' that were maybe not a good idea to begin with,
or somehow ditching the 'timestamp' vs. 'timestamptz' distinction, or
changing to 64-bit Oids, such that software that interacts with postgresql
has to change accordingly.  Another such idea would be supporting 64-bit
varlena lengths and dropping large object support.  Another would be
dropping support for older communication protocols whose presence in the
server out of the box makes the server a security vulnerability.  (I am not
asserting the presence of such vulnerabilities, but just speculating on the
possibility that such vulnerabilities might be discovered in the future that
make it useful to ditch older, insecure protocols.)

I suspect other folks could add lots of other stuff to this list.


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

mark