wieck@debis.com (Jan Wieck) writes:
> If we really go for a 6.6 release, we need to branch off from
> the 6.5 tree and backpatch things we want to have in 6.6 into
> there. Releasing some snapshot of the current 7.0 tree as 6.6
> IMHO is a risk we cannot estimate.
I agree with Jan that we can't just fire something out the door based
on current sources. There are enough poorly-tested or half-done
changes in there that we'd need a long beta cycle to have much
confidence in it. I think this would drain an unreasonable amount of
developer time that would be better spent on finishing the half-done
stuff ... and *then* starting a long beta cycle ;-).
We are at a midflight point now. We don't have enough stuff done to
put out a 7.0, but neither are we close enough to the last release
to put out something that would fairly be called 6.6. I think users
would expect a "6.6" to offer small improvements featurewise and
continue in the trend of improving stability/performance. I'm not
sure I could promise that a 6.6 would be more stable than 6.5. At
least not without that long beta cycle.
We can continue to make 6.5.* releases if any critical problems come up,
but that again is a drain on developer time, so I'm not enthused about
making 6.5.* releases unless necessary.
In short, I'd rather continue on the present course and not be overly
concerned about how long it takes to get it right. Schedule-driven
decisions are usually wrong decisions, in my experience.
regards, tom lane