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.

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, Pennsylvania 19026

Ditto.

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

MikeA

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, Pennsylvania 19026

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