Обсуждение: 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[@]dcc.uchile.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@agliodbs.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@gmx.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@gmx.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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Hello,<br /><br /> Version 7.5 is as close to a major release as I have seen in the almost 9 years I have been using
PostgreSQL.<br/> This release brings about a lot of "enterprise" features that have been holding back PostgreSQL in a
bigway for<br /> for a long time.<br /><br /> All of my serious customers; potential, existing and past has all at one
pointor another requested most if not<br /> all of the features being released onto the world with 7.5. In fact the
onlyones that I can think of off the top <br /> of my head that isn't in the current list of availables is table
partitioningand to a lesser extent two phase commit.<br /><br /> This release definately deserves a major version jump.
Ifit were up to me it would be more than one (I would<br /> call it 10h for obvious reasons. O.k. the h is a joke but I
amserious about the 10) just from a marketing <br /> standpoint. I could argue a major version jump just from the fact
thatwe finally have a port to the most used <br /> operating system (regardless if that is good or bad) in the
world.<br/><br /> Sincerely,<br /><br /> Joshua D. Drake<br /><br /><br /><br /><br /> Tom Lane wrote:<br /><blockquote
cite="mid4010.1091319264@sss.pgh.pa.us"type="cite"><pre wrap="">Josh Berkus <<a class="moz-txt-link-abbreviated"
href="mailto:josh@agliodbs.com">josh@agliodbs.com</a>>writes: </pre><blockquote type="cite"><pre wrap="">Even if
Savepointsdon't make it, we'll still have: </pre></blockquote><pre wrap="">
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
</pre><blockquote type="cite"><pre wrap="">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? </pre></blockquote><pre wrap="">
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 </pre></blockquote><br /><br /><pre class="moz-signature" cols="72">--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - <a class="moz-txt-link-abbreviated" href="mailto:jd@commandprompt.com">jd@commandprompt.com</a> - <a
class="moz-txt-link-freetext"href="http://www.commandprompt.com">http://www.commandprompt.com</a>
PostgreSQL Replicator -- production quality replication for PostgreSQL</pre>
>>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@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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
On Sat, Jul 31, 2004 at 22:40:52 -0700, Steve Atkins <steve@blighty.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@hub.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
After takin a swig o' Arrakan spice grog, Gaetano Mendola <mendola@bigfoot.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
Christopher Browne <cbbrowne@acm.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
Christopher Browne wrote: > After takin a swig o' Arrakan spice grog, Gaetano Mendola <mendola@bigfoot.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
Tom Lane <tgl@sss.pgh.pa.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