Peter Eisentraut <peter_e@gmx.net> writes:
> Alvaro Herrera wrote:
>> What was the rule for increasing the first number after just before
>> 7.0?
> That was just to avoid having to release a 6.6.6, which Jan had clearly
> been working towards. :-)
AFAIR, we had informally been referring to that release as 6.6 right up
until about the start of beta, when it was proposed that it should be
called 7.0 because of the extent of the changes since 6.5, and that
motion carried. If we decide now to rename 7.5 to 8.0, it will be
exactly the same process. I don't think Peter's process-based
objections are valid at all.
It strikes me that we have more than enough major changes since 7.4 to
justify calling this 8.0, both in terms of major features that users
have been asking for, and in terms of the extent of internal
reorganization (and consequent need for beta testing ...).
> Seriously, major version jumps correspond to epoch-like changes, like
> when the code moved out of Berkeley, or when we switched from bug
> fixing to adding features.
Two commments about that. One, I think you are engaging in historical
revisionism about the reason for the 6.6/7.0 renaming. I don't recall
that 7.0 marked any particular watershed in terms of our general bug
level, nor that we saw it in those terms when we decided to renumber.
Two, I think 7.5/8.0 will indeed be epochal in terms of the size of our
user community. Win32 native support will mean a great deal on the low
end, and savepoints, PITR, and reliable replication (Slony) will mean a
great deal in terms of our credibility as an enterprise-class database.
regards, tom lane
PS: IIRC I was on the "nay" side in the 6.6-to-7.0 rename vote, so I
think I definitely have standing to be in favor this time.