Re: 10.0

Mark Dilger <hornschnorter(at)gmail(dot)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.

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

regards, tom lane