Re: [HACKERS] Version Numbering -- The great debate
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Version Numbering -- The great debate
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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Version Numbering -- The great debate
On Sat, Jul 31, 2004 at 22:40:52 -0700, Steve Atkins [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Version Numbering -- The great debate
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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Version Numbering -- The great debate
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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Version Numbering -- The great debate
After takin a swig o' Arrakan spice grog, Gaetano Mendola [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Version Numbering -- The great debate
Christopher Browne wrote: After takin a swig o' Arrakan spice grog, Gaetano Mendola [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Version Numbering -- The great debate
Christopher Browne [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Version Numbering -- The great debate
Tom Lane [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Version Numbering -- The great debate
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/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Version Numbering -- The great debate
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Version Numbering -- The great debate
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/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Version Numbering -- The great debate
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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Version Numbering -- The great debate
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 ([EMAIL PROTECTED]) Vivir y dejar de vivir son soluciones imaginarias. La existencia está en otra parte (Andre Breton) ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Version Numbering -- The great debate
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/ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Version Numbering -- The great debate
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/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Version Numbering -- The great debate
Josh Berkus [EMAIL PROTECTED] 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
Re: [HACKERS] Version Numbering -- The great debate
Peter Eisentraut [EMAIL PROTECTED] 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
Re: [HACKERS] Version Numbering -- The great debate
I am fine with either numbering, but I think the 8.0 might make more sense. --- Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Version Numbering -- The great debate
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 [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL
Re: [HACKERS] Version Numbering -- The great debate
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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Version Numbering -- The great debate
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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Version Numbering -- The great debate
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Version Numbering -- The great debate
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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
