Re: Version Numbering -- The great debate

Folks,

Well, we're past feature freeze and with one reservation we know what's in the
next version. After talking to several people at OSCON, I want to revive a
discussion: whether this is 7.5 or 8.0. We tabled that discussion in April
pending a feature list.

Even if Savepoints don't make it, we'll still have:

Win32 Port
LRU/Background Writer/Lazy Vacuum
PITR
Tablespaces
AutoVacuum in backend
$$dollar_quoting$$
Re-typing columns
New PL/perl
CSV import/export

This is more features worth mentioning than we've ever had in a single release
before -- and if you consider several add-ons which have been
implemented/improved at the same time (Slony, PL/Java, etc.) it's even more
momentous. If this isn't 8.0, then what will be?

I talked to a few of our people at OSCON who agreed with me. We'd need to
settle this before we officially enter beta. Responses?

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:
> This is more features worth mentioning than we've ever had in a
> single release before

We've also never had a single release before that had its version number
jump determined by the number of features.

> I talked to a few of our people at OSCON who agreed with me. We'd
> need to settle this before we officially enter beta. Responses?

Considering that beta starts in about 3 hours -- 7.5 it is.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter,

> We've also never had a single release before that had its version number
> jump determined by the number of features.

That's a non-argument, Peter; we don't have any clear criteria for version
number jump.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:
> > We've also never had a single release before that had its version
> > number jump determined by the number of features.
>
> That's a non-argument, Peter; we don't have any clear criteria for
> version number jump.

Oh yes, we have very clear criteria: For patch releases, we increase the
third number, for feature releases we increase the second number and
set the third number to zero. Clear enough?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter,

> Oh yes, we have very clear criteria: For patch releases, we increase the
> third number, for feature releases we increase the second number and
> set the third number to zero. Clear enough?

So, as far as you're concerned, there will never ever be an 8.0.

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Sun, Aug 01, 2004 at 12:02:47AM +0200, Peter Eisentraut wrote:
> Josh Berkus wrote:
> > > We've also never had a single release before that had its version
> > > number jump determined by the number of features.
> >
> > That's a non-argument, Peter; we don't have any clear criteria for
> > version number jump.
>
> Oh yes, we have very clear criteria: For patch releases, we increase the
> third number, for feature releases we increase the second number and
> set the third number to zero. Clear enough?

What was the rule for increasing the first number after just before 7.0?

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"Vivir y dejar de vivir son soluciones imaginarias.
La existencia está en otra parte" (Andre Breton)

Alvaro Herrera wrote:
> What was the rule for increasing the first number after just before
> 7.0?

That was just to avoid having to release a 6.6.6, which Jan had clearly
been working towards. :-)

Seriously, major version jumps correspond to epoch-like changes, like
when the code moved out of Berkeley, or when we switched from bug
fixing to adding features. Maybe the next epoch would be after a
hostile takeover of firebird. But right now I see no epoch change,
just a potential for confusing users. Consistency and humbleness can
be a virtue.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Josh Berkus wrote:
> So, as far as you're concerned, there will never ever be an 8.0.

Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Even if Savepoints don't make it, we'll still have:

Savepoints are in, as is exception-trapping in functions (at least
plpgsql, the other PLs are on their own :-().

Some other major improvements you didn't mention:

Cross-datatype comparisons are indexable (at least for common
combinations); this solves a huge performance gotcha

Dependency-aware pg_dump

Much more complete support for rowtype operations

> This is more features worth mentioning than we've ever had in a single release
> before -- and if you consider several add-ons which have been
> implemented/improved at the same time (Slony, PL/Java, etc.) it's even more
> momentous. If this isn't 8.0, then what will be?

I tend to agree, and was about to bring up the point myself.

regards, tom lane

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Alvaro Herrera wrote:
>> What was the rule for increasing the first number after just before
>> 7.0?

> That was just to avoid having to release a 6.6.6, which Jan had clearly
> been working towards. :-)

AFAIR, we had informally been referring to that release as 6.6 right up
until about the start of beta, when it was proposed that it should be
called 7.0 because of the extent of the changes since 6.5, and that
motion carried. If we decide now to rename 7.5 to 8.0, it will be
exactly the same process. I don't think Peter's process-based
objections are valid at all.

It strikes me that we have more than enough major changes since 7.4 to
justify calling this 8.0, both in terms of major features that users
have been asking for, and in terms of the extent of internal
reorganization (and consequent need for beta testing ...).

> Seriously, major version jumps correspond to epoch-like changes, like
> when the code moved out of Berkeley, or when we switched from bug
> fixing to adding features.

Two commments about that. One, I think you are engaging in historical
revisionism about the reason for the 6.6/7.0 renaming. I don't recall
that 7.0 marked any particular watershed in terms of our general bug
level, nor that we saw it in those terms when we decided to renumber.

Two, I think 7.5/8.0 will indeed be epochal in terms of the size of our
user community. Win32 native support will mean a great deal on the low
end, and savepoints, PITR, and reliable replication (Slony) will mean a
great deal in terms of our credibility as an enterprise-class database.

regards, tom lane

PS: IIRC I was on the "nay" side in the 6.6-to-7.0 rename vote, so I
think I definitely have standing to be in favor this time.

I am fine with either numbering, but I think the 8.0 might make more
sense.

---------------------------------------------------------------------------

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Alvaro Herrera wrote:
> >> What was the rule for increasing the first number after just before
> >> 7.0?
>
> > That was just to avoid having to release a 6.6.6, which Jan had clearly
> > been working towards. :-)
>
> AFAIR, we had informally been referring to that release as 6.6 right up
> until about the start of beta, when it was proposed that it should be
> called 7.0 because of the extent of the changes since 6.5, and that
> motion carried. If we decide now to rename 7.5 to 8.0, it will be
> exactly the same process. I don't think Peter's process-based
> objections are valid at all.
>
> It strikes me that we have more than enough major changes since 7.4 to
> justify calling this 8.0, both in terms of major features that users
> have been asking for, and in terms of the extent of internal
> reorganization (and consequent need for beta testing ...).
>
> > Seriously, major version jumps correspond to epoch-like changes, like
> > when the code moved out of Berkeley, or when we switched from bug
> > fixing to adding features.
>
> Two commments about that. One, I think you are engaging in historical
> revisionism about the reason for the 6.6/7.0 renaming. I don't recall
> that 7.0 marked any particular watershed in terms of our general bug
> level, nor that we saw it in those terms when we decided to renumber.
>
> Two, I think 7.5/8.0 will indeed be epochal in terms of the size of our
> user community. Win32 native support will mean a great deal on the low
> end, and savepoints, PITR, and reliable replication (Slony) will mean a
> great deal in terms of our credibility as an enterprise-class database.
>
> regards, tom lane
>
> PS: IIRC I was on the "nay" side in the 6.6-to-7.0 rename vote, so I
> think I definitely have standing to be in favor this time.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Hello,

Version 7.5 is as close to a major release as I have seen in the almost
9 years I have been using PostgreSQL.
This release brings about a lot of "enterprise" features that have been
holding back PostgreSQL in a big way for
for a long time.

All of my serious customers; potential, existing and past has all at one
point or another requested most if not
all of the features being released onto the world with 7.5. In fact the
only ones that I can think of off the top
of my head that isn't in the current list of availables is table
partitioning and to a lesser extent two phase commit.

This release definately deserves a major version jump. If it were up to
me it would be more than one (I would
call it 10h for obvious reasons. O.k. the h is a joke but I am serious
about the 10) just from a marketing
standpoint. I could argue a major version jump just from the fact that
we finally have a port to the most used
operating system (regardless if that is good or bad) in the world.

Sincerely,

Joshua D. Drake

Tom Lane wrote:

>Josh Berkus <josh(at)agliodbs(dot)com> writes:
>
>
>>Even if Savepoints don't make it, we'll still have:
>>
>>
>
>Savepoints are in, as is exception-trapping in functions (at least
>plpgsql, the other PLs are on their own :-().
>
>Some other major improvements you didn't mention:
>
>Cross-datatype comparisons are indexable (at least for common
>combinations); this solves a huge performance gotcha
>
>Dependency-aware pg_dump
>
>Much more complete support for rowtype operations
>
>
>
>
>>This is more features worth mentioning than we've ever had in a single release
>>before -- and if you consider several add-ons which have been
>>implemented/improved at the same time (Slony, PL/Java, etc.) it's even more
>>momentous. If this isn't 8.0, then what will be?
>>
>>
>
>I tend to agree, and was about to bring up the point myself.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
>
>

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

>>So, as far as you're concerned, there will never ever be an 8.0.
>
>
> Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0.

How about 7.5i :)

Chris

>>This is more features worth mentioning than we've ever had in a single release
>>before -- and if you consider several add-ons which have been
>>implemented/improved at the same time (Slony, PL/Java, etc.) it's even more
>>momentous. If this isn't 8.0, then what will be?
>
>
> I tend to agree, and was about to bring up the point myself.

I'm in favour of 8.0. There's a time to be humble and a time for hard
work to be properly recognised.

Chris

Christopher Kings-Lynne wrote:
> >>This is more features worth mentioning than we've ever had in a single release
> >>before -- and if you consider several add-ons which have been
> >>implemented/improved at the same time (Slony, PL/Java, etc.) it's even more
> >>momentous. If this isn't 8.0, then what will be?
> >
> >
> > I tend to agree, and was about to bring up the point myself.
>
> I'm in favour of 8.0. There's a time to be humble and a time for hard
> work to be properly recognized.

FYI, the move to 7.0 was done after we realized that 6.5 should have
been numbered 7.0.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Sun, Aug 01, 2004 at 12:20:59PM +0800, Christopher Kings-Lynne wrote:
> >>This is more features worth mentioning than we've ever had in a single
> >>release before -- and if you consider several add-ons which have been
> >>implemented/improved at the same time (Slony, PL/Java, etc.) it's even
> >>more momentous. If this isn't 8.0, then what will be?
> >
> >
> >I tend to agree, and was about to bring up the point myself.
>
> I'm in favour of 8.0. There's a time to be humble and a time for hard
> work to be properly recognised.

We deploy postgresql as part of an application that goes out to big,
IT-savvy corporations. So far we've shipped 7.2.* and 7.4.* (the
upgrade pain to 7.3 outweighed the benefits, so we put that off
and put it off until 7.4 was available).

8.0.0 suggests, to my customers at least, a brand new release with
either massive re-architecting, many new features or both and that's
likely to be riddled with bugs. While it would be unlikely that we'd
ship 7.5.0 to customers (I suspect there'd be a .1 release before we
were comfortable with the .0 release, given the massive changes)
there's not a chance we'd ship 8.0.0 - even though it's the identical
codebase - because of that perception. Probably not 8.0.1 either.

From the discussions I've seen and the number and size of changes I've
seen go into the codebase recently I suspect 8.0.0 might be quite an
appropriate version number on several levels. There have been a lot of
major changes in this release, some significant enough, I think,
anyway, to justify a bump in major version number.

Those major changes touch the code everywhere (especially nested
transactions - where the breadth of the changes scares me) and are
likely to lead to a number of obscure bugs that will be problematic
and will probably survive through an extended beta period. People are
likely to expect more bugs in a .0.0 release - but that also means
they're likely to be much more tolerant of them ("nice functionality,
but some problematic bugs - but it's a .0.0 release, so we expect some
bugs, but we also expect the .0.2 or .1.0 release to be _really_
good.").

So, from a managing customer expectations POV, 8.0.0 looks an
appropriate version number for at least two major reasons. I'd rather
end-users treat this release as a development/preview release, forgive
the bugs and take a minor release or two before expecting the level of
stability _we_ expect from postgresql - and I suspect that may be
doubly appropriate for the large base of potential win32 users.

Just a perspective from a company that uses and redistributes
PostgreSQL to end-users.

Cheers,
Steve

Joshua D. Drake wrote:
> Hello,
>
> Version 7.5 is as close to a major release as I have seen in the almost
> 9 years I have been using PostgreSQL.
> This release brings about a lot of "enterprise" features that have been
> holding back PostgreSQL in a big way for
> for a long time.
>
> All of my serious customers; potential, existing and past has all at one
> point or another requested most if not
> all of the features being released onto the world with 7.5. In fact the
> only ones that I can think of off the top
> of my head that isn't in the current list of availables is table
> partitioning and to a lesser extent two phase commit.
>
> This release definately deserves a major version jump. If it were up to
> me it would be more than one (I would
> call it 10h for obvious reasons. O.k. the h is a joke but I am serious
> about the 10) just from a marketing
> standpoint. I could argue a major version jump just from the fact that
> we finally have a port to the most used
> operating system (regardless if that is good or bad) in the world.
>
> Sincerely,
>
> Joshua D. Drake

They have tried to do the same for "With Naked Gun" (I think it is
called in English). They called the second film "With Naked Gun 2 1/2".
The third version was called "33 1/3" then ...
Maybe the tenth film would be 10^256 then ...

8.0 would be ok but I am pretty against jumping version number - they
have such a pure marketing flavour ("we have a high version number but
we don't know what else we should tell you about the new release").
Database work should be "conservative" which means slowly but surely ...
- from my point of view this conflicts with pumping version numbers. I
don't think there will be one more user just because of a different
version number.

Maybe a hostily overtake of Oracle (not Firebird as mentioned by Peter)
would justify 10.0.0 ;).

Regards,

Hans

--
Cybertec Geschwinde u Schoenig
Schoengrabern 134, A-2020 Hollabrunn, Austria
Tel: +43/720/10 1234567 or +43/664/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at

Peter Eisentraut wrote:

> Alvaro Herrera wrote:
>
>>What was the rule for increasing the first number after just before
>>7.0?
>
>
> That was just to avoid having to release a 6.6.6, which Jan had clearly
> been working towards. :-)
>
> Seriously, major version jumps correspond to epoch-like changes, like
> when the code moved out of Berkeley, or when we switched from bug
> fixing to adding features. Maybe the next epoch would be after a
> hostile takeover of firebird. But right now I see no epoch change,
> just a potential for confusing users. Consistency and humbleness can
> be a virtue.

Have a win32 native implementation is not a epoch change about you ?

Regards
Gaetano Mendola

After takin a swig o' Arrakan spice grog, Gaetano Mendola <mendola(at)bigfoot(dot)com> belched out:
> Peter Eisentraut wrote:
>
>> Alvaro Herrera wrote:
>>
>>>What was the rule for increasing the first number after just before
>>>7.0?
>> That was just to avoid having to release a 6.6.6, which Jan had
>> clearly been working towards. :-)
>> Seriously, major version jumps correspond to epoch-like changes,
>> like when the code moved out of Berkeley, or when we switched from
>> bug fixing to adding features. Maybe the next epoch would be after
>> a hostile takeover of firebird. But right now I see no epoch
>> change, just a potential for confusing users. Consistency and
>> humbleness can be a virtue.
>
> Have a win32 native implementation is not a epoch change about you ?

I saw mention in the thread that the shift to 7.0 took place when
people realized that 6.5 should have been 7.0.

I think that the set of new features here will fairly likely warrant
the "8.0" moniker; the 'consistent' way to go would be to call this
version 7.5, and then 8.0 would soon follow, and be the release where
some degree of improved "maturity" has been achieved for:

a) Win32 support

b) Nested transactions (thereby leading to the ability to have
exception handling support in stored procedures)

c) PITR.

It would be surprising for these to all be _completely_ ready for all
purposes come 7.5.0.

The reasonable thing might be to say "Forget 7.5.1; call it 8.0!"
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/linuxdistributions.html
Computers in the future may weigh no more than 1.5 tons. -Popular
Mechanics, forecasting the relentless march of science, 1949

On Sat, Jul 31, 2004 at 22:40:52 -0700,
Steve Atkins <steve(at)blighty(dot)com> wrote:
>
> 8.0.0 suggests, to my customers at least, a brand new release with
> either massive re-architecting, many new features or both and that's
> likely to be riddled with bugs. While it would be unlikely that we'd
> ship 7.5.0 to customers (I suspect there'd be a .1 release before we
> were comfortable with the .0 release, given the massive changes)
> there's not a chance we'd ship 8.0.0 - even though it's the identical
> codebase - because of that perception. Probably not 8.0.1 either.

I think that using 8.0.0 will be a good way to warn people that this
version needs to be handled more carefully than previous versions
because of the breadth of the changes.

However, there was also a previous version discussion that had to do
with being able to upgrades without dumps and using the first number
to indicate when a dump and reload was needed. When the second number
changed there was supposed to be a process that could do the necessary
changes without forcing a dump and reload.

On Sun, 1 Aug 2004, Peter Eisentraut wrote:

> Alvaro Herrera wrote:
>> What was the rule for increasing the first number after just before
>> 7.0?
>
> That was just to avoid having to release a 6.6.6, which Jan had clearly
> been working towards. :-)
>
> Seriously, major version jumps correspond to epoch-like changes, like
> when the code moved out of Berkeley, or when we switched from bug
> fixing to adding features. Maybe the next epoch would be after a
> hostile takeover of firebird. But right now I see no epoch change,
> just a potential for confusing users. Consistency and humbleness can
> be a virtue.

Okay, just to pop in here ...

I agree with Peter (re: features) ... but, I do think that this release
could be said to have an 'epoch-like' change ... we now support Windows
natively. Up until now, we've been a *Unix* database (I don't care if
that Unix happens to be Solaris, Linux or SCO ... its all *Unix*) ...

Based on that (and that alone), I'd argue for an 8.0 release ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Peter,

> Eventually we'll do the Sun switcheroo and follow release 7.12 by 13.0.

Even better, we can have two different, parallel version numbers, so that the
next version can be 7.5 *and* 13.0.

--
Josh Berkus
Aglio Database Solutions
San Francisco

Christopher Browne wrote:
> After takin a swig o' Arrakan spice grog, Gaetano Mendola <mendola(at)bigfoot(dot)com> belched out:
>
>>Peter Eisentraut wrote:
>>
>>
>>>Alvaro Herrera wrote:
>>>
>>>
>>>>What was the rule for increasing the first number after just before
>>>>7.0?
>>>
>>>That was just to avoid having to release a 6.6.6, which Jan had
>>>clearly been working towards. :-)
>>>Seriously, major version jumps correspond to epoch-like changes,
>>>like when the code moved out of Berkeley, or when we switched from
>>>bug fixing to adding features. Maybe the next epoch would be after
>>>a hostile takeover of firebird. But right now I see no epoch
>>>change, just a potential for confusing users. Consistency and
>>>humbleness can be a virtue.
>>
>>Have a win32 native implementation is not a epoch change about you ?
>
>
> I saw mention in the thread that the shift to 7.0 took place when
> people realized that 6.5 should have been 7.0.
>
> I think that the set of new features here will fairly likely warrant
> the "8.0" moniker; the 'consistent' way to go would be to call this
> version 7.5, and then 8.0 would soon follow, and be the release where
> some degree of improved "maturity" has been achieved for:
>
> a) Win32 support
>
> b) Nested transactions (thereby leading to the ability to have
> exception handling support in stored procedures)
>
> c) PITR.
>
> It would be surprising for these to all be _completely_ ready for all
> purposes come 7.5.0.
>
> The reasonable thing might be to say "Forget 7.5.1; call it 8.0!"

Instead I think is good release a 8.0 in order to underline that this could
be more buggy then a very stable 7.x series.

Regards
Gaetano Mendola

Christopher Browne <cbbrowne(at)acm(dot)org> writes:
> I think that the set of new features here will fairly likely warrant
> the "8.0" moniker; the 'consistent' way to go would be to call this
> version 7.5, and then 8.0 would soon follow, and be the release where
> some degree of improved "maturity" has been achieved for:

Huh? That is exactly counter to most people's expectations about
version numbering. N.0 is the unstable release, N.1 is the one
with some bugs shaken out. If we release a 7.5 people will expect
it to be less buggy than 7.4, and I'm not sure we can promise that.

regards, tom lane

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Huh? That is exactly counter to most people's expectations about
> version numbering. N.0 is the unstable release, N.1 is the one
> with some bugs shaken out. If we release a 7.5 people will expect
> it to be less buggy than 7.4, and I'm not sure we can promise that.

I agree with this, and from my non-authoritative viewpoint as a user
and rabid advocate, I think we should be going with 8.0 for this
release as well. :)

-Doug
--
Let us cross over the river, and rest under the shade of the trees.
--T. J. Jackson, 1863