Re: [HACKERS] 6.6 release

On Fri, 10 Dec 1999, Vince Vielhaber wrote:

> On Fri, 10 Dec 1999, The Hermit Hacker wrote:
> 
> > Here's a question...should we beta on Feb 1st but make it 7.0?  If we are
> > going to be looking for a "long slog" for 7, why not "freeze" things on
> > Feb 1st as v7, and start working on v8 with WAL, long tuples, etc, etc...
> > 
> > Like, what point do we call things a major release?  In a sense, MVCC
> > probably should have been considered a large enough overhaul to warrant
> > 7.0, no?
> 
> I thought Marc decided[1] last year to drop the minor.minor version
> numbers.  IOW, there would be no 6.6.1, 6.6.2, etc.  Make the upcoming
> release 7.0 and take care of any minor glitches in it as 7.1, 7.2 and
> when WAL and the other stuff is ready - or as it's ready - release 8.0
> and fix any glitches as 8.1, etc.  Currently every minor release is really
> a major one, so why not just mark it as such and not worry about it?
> 
> Vince.
> 
> [1] Or did you do that on inn-workers and not here?  It was about the same
> time FreeBSD dropped the major.minor.minor for the major.minor numbering.

Would have been here...

The problem, as I see it, is that the FreeBSD camp is more "strict" in how
it does their source tree...there is a development tree (X.y), and a
stable tree (X-1.y)...if something is back-patchable to X-1.y from X.y, it
gets done (ie. bug fixes, security fixes or even feature changes *as long
as* they don't change the API...

We're about 50% there, but not completely...this last release (6.5) has
been fantastic...ppl have been back-patching to the 6.5 tree, providing us
wiht interim releases, but not to the level that we can build a 6.6 off
that tree...

when we do up Release 7, which I'd like to make this one, I'd *love* to
make this a whole-hog thing...tag/branch things as REL_7, no minor
number...then its up to the developers to decide whether something is
back-patchable (like they've been doing up until now) with a periodic
release put out while Release 8 is being worked on.

It slows down the rush of getting a full release out while allowign ppl
access to the debug'd advances in the upcoming release...


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