Vadim Mikheev <vadim@krs.ru> writes:
>> I agreed! I propose to name the next release as 6.6
> ^^^
> or 7.0
>> and the "WAL" release as 7.0 or 6.7, but not 8.0...
> ^^^
> and 7.1
7.0 and 7.1 seem like the worst choice of names to me. We are not
planning any major new features for the Feb release (except for whatever
part of foreign key support Jan has working by then). There will be
some major new features for the release-after-that: WAL, some kind of
answer for the long-tuple problem, etc. etc. So it'd be very confusing
to users to call this one a "major" version bump, when it will have less
new stuff in it than the "minor" version bumps before and after.
I could live with 7.0 and then 8.0, if we were going to switch to
two-part instead of three-part version numbering. But I agree with
Thomas that I'd rather stick to the convention we have been using.
If we are going to be consistent with the way we have named prior
releases, it seems to me that there is no choice: the Feb release
is 6.6, and the one after it will be 7.0 (or maybe even 6.7).
I also would rather do it that way because I think the idea is to
wrap up *what we have now* and get it out. If we call the Feb release
7.0, then Thomas will want to cram in date/time type consolidation work
that (AFAIK) he hasn't even started on, and there'll be great temptation
to try to squeeze in other half-baked stuff in order to try to justify
calling this a major version bump. That's completely at odds with what
I thought the proposal of a near-term release was all about.
Basically, if people insist that the next release should be called 7.0,
I'd be inclined to forget about a near-term release and go back to
Plan A: keep working on it until we have enough stuff done to justify
calling it 7.0.
regards, tom lane