Обсуждение: New version number 6.6 or 7.0
Can I have votes on what people want the next version number to be? We have to brand the release when we start development(PG_VERSION file). 6.5 probably should have been called 7.0, but we had already committed to 6.5. -- 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, Pennsylvania19026
> Can I have votes on what people want the next version number to be?
> We have to brand the release when we start development(PG_VERSION
> file). 6.5 probably should have been called 7.0, but we had already
> committed to 6.5.
We've been making pretty steady progress over the last few releases.
I'd suggest that a bump to 7.0 should happen when we've accumulated
most of the fixes/improvements from the "hot list". We've worked
through most of those; here are the ones I'd like to see at or before
a 7.0 release:
o implement outer joins
o merge date/time types and deprecate the old 4-byte ones
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
>
> Can I have votes on what people want the next version number to be?
>
> We have to brand the release when we start development(PG_VERSION file).
> 6.5 probably should have been called 7.0, but we had already committed
> to 6.5.
6.6.6 - the number of the databeast :-)
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
>
> Can I have votes on what people want the next version number to be?
>
> We have to brand the release when we start development(PG_VERSION file).
> 6.5 probably should have been called 7.0, but we had already committed
> to 6.5.
Now seriously:
Naming it 7.0 IMHO requires transaction log, tuple split over
blocks, foreign keys, outer joins and rules of arbitrary
size. I don't expect ALL of them for the next release, so let
it be 6.6.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
> Naming it 7.0 IMHO requires transaction log, tuple split over
> blocks, foreign keys, outer joins and rules of arbitrary
> size. I don't expect ALL of them for the next release, so let
> it be 6.6.
I like Jan's more complete list...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > Naming it 7.0 IMHO requires transaction log, tuple split over > > blocks, foreign keys, outer joins and rules of arbitrary > > size. I don't expect ALL of them for the next release, so let > > it be 6.6. > > I like Jan's more complete list... OK, 6.6 is it. -- 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, Pennsylvania19026
On Sat, 17 Jul 1999, Thomas Lockhart wrote:
> > Can I have votes on what people want the next version number to be?
> > We have to brand the release when we start development(PG_VERSION
> > file). 6.5 probably should have been called 7.0, but we had already
> > committed to 6.5.
>
> We've been making pretty steady progress over the last few releases.
> I'd suggest that a bump to 7.0 should happen when we've accumulated
> most of the fixes/improvements from the "hot list". We've worked
> through most of those; here are the ones I'd like to see at or before
> a 7.0 release:
>
> o implement outer joins
> o merge date/time types and deprecate the old 4-byte ones
My opinion is that MVCC should have jump'd us to 7.0 in the first
place...
IMHO, release for October should be v7.0 ... if the above two get done,
great, if not, no probs...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > We've been making pretty steady progress over the last few releases. > > I'd suggest that a bump to 7.0 should happen when we've accumulated > > most of the fixes/improvements from the "hot list". We've worked > > through most of those; here are the ones I'd like to see at or before > > a 7.0 release: > > > > o implement outer joins > > o merge date/time types and deprecate the old 4-byte ones > > My opinion is that MVCC should have jump'd us to 7.0 in the first > place... > > IMHO, release for October should be v7.0 ... if the above two get done, > great, if not, no probs... Due to overwhelming agreement, it is 6.6. I personally vote for 7.0, and so do you, but we are outnumbered. We can revisit this as the release gets closer, but to change it then, I am going to have to change PG_VERSION, and that will require initdb for everyone. Perhaps just before we enter beta, we can discuss it, knowing then what our features will be. -- 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, Pennsylvania19026
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> We can revisit this as the
> release gets closer, but to change it then, I am going to have to change
> PG_VERSION, and that will require initdb for everyone. Perhaps just
> before we enter beta, we can discuss it, knowing then what our features
> will be.
We usually cause enough initdb's during a development cycle that another
one doesn't seem like a big problem. Let's leave it at 6.6 for now, and
wait to see what the feature list looks like when it's time to start
beta.
regards, tom lane