Re: [HACKERS] 6.6 release - Mailing list pgsql-hackers

On Fri, 10 Dec 1999, Thomas Lockhart wrote:

> Marc, I'd like to understand why we are pushing 7.0 for this "release
> where we are" release. We've (perhaps) got FK support, and a rewritten
> psql, and lots of bug fixes, and maybe "join syntax" but not outer
> joins. If we release as 7.0, then I'll force the date/time
> reunification into this release, since it is a pretty big change to
> the backend tables (I've been waiting quite a while already for the
> major rev jump to do this).
> 
> But we won't have WAL, outer joins, rewritten query tree, etc etc so
> why are we pushing the major rev jump now? imho rewriting the query
> tree, which affects the parser, planner, optimizer, and perhaps
> executor, is as invasive as we'll get; that and WAL should trigger
> 7.0. 
> 
> btw, I'm not really happy with the prospect/suggestion of going from
> 7.0 to 8.0 in a short time period; one of things I'm most satisfied
> with in our development is that we have significant minor releases and
> that we haven't succumbed to the "major rev only" marketing driven
> ploys of the big guys...

FreeBSD (my role model, always has been) has two trees right now...4.0,
which is the development tree (ie. what I'm proposing as our 8.0), and,
currently, 3.3 for their stable tree.  Anything new and wonderful goes
into 4.0...anything deemed "safe" gets back patched to 3.x and
periodically released.

The idea is that anyone can throw anything (within reason) into the 8.0
tree while we still have a stable branch to work on and make releases
on...so any "safe features" can be back-patched to 7.x.  

Damn damn damn...I can never explain these things right.  The 7.x would,
*at all times* maintain database compatibility with any 7.x release...I
could cvsup down the newest source, build and install it, without any risk
to my current databases...but still get access to a newer feature
set.  After a few months of development, like now, we freeze the 7.x
branch and do up a release (7.1) that packages things up.

For instance, if you look at Hub, its running 3.4-RC right now...FreeBSD
just did a 'freeze' for a 3.4 release, and because Hub has its kernel
updated periodically through cvsup, the 'uname -a' output changes with...I
basically keep up with the latest *stable* version of FreeBSD on Hub, but
my home machine, using the same mechanism, runs 4.0-CURRENT, a totally
developmental/experimental version...

I think the project has gotten to such a size, and such a number of
developers, that this is feasible to do...we'd still have our major
releases, but only have minor, not minor.minor releases...

Instead of v6.5.1 after a month of v6.5 being released, we'd have released
v6.6 as being the more current stable version...its just taking things one
step further then what we've done recently with the release of v6.5.3...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org