Re: [HACKERS] 6.6 release

Okay, this whole thread could continue going back and forth for the next 6
months and we may as well wait for WAL :)

It is agreed that Feb 1st is the beta date...it will not include WAL, but
will be numbered v7.0, with v7.1 going BETA as soon as Vadim feels
prepared with the WAL code...

Altho I would personally like to get rid of the major.minor.minor
numbering scheme, and just have it major.minor, the arguments against vs
for outweigh, so we'll stick with what we've always had in that regard...

On Feb 1st, the CVS repository will be branched, like we did on the last
release, so that we can beta/debug 7.0 *without* interfering with
development on 7.1.  This has proven to work quite well with v6.5.x, as
far as I'm concerned...since, once we go beta, there are to be no new
features, only bug fixes, this shouldn't affect anyone, eh? :)



On Sun, 12 Dec 1999, Bruce Momjian wrote:

> > 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.
> 
> Let's look at the 7.0 features list:
> 
>         Foreign Keys    - Jan
>         WAL             - Vadim
>         Function args   - Tom
>         System indexes  - Bruce
>         Date/Time types - Thomas
>         Optimizer       - Tom
> 
>         Outer Joins     - Thomas?
>         Long Tuples     - ?
> 
> We have foreign keys and long tuples in Feb 1.  Jan says on�long tuples:
> 
>     I  thought  about  the  huge size variable text type a little
>     more.  And I think I could get the  following  implementation
>     to work reliable for our upcoming release.
> 
> The more we explore long tuples, it seems easier than expected. 
> Chaining tuples was going to be hard. The new way is more efficient, and
> easier.
> 
> I assume Thomas may do the date/time for Feb 1 because it mostly
> removing old types, I think.
> 
> So, we will not have WAL for Feb 1, but people are clammoring for
> foreign keys and long tuples.  I think 7.0 is good for Feb 1. We can add
> WAL in 7.1.
> 
> -- 
>   Bruce Momjian                        |  http://www.op.net/~candle
>   maillist@candle.pha.pa.us            |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
> 
> ************
> 

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