Re: [HACKERS] Version Numbering
Hi, On 08/21/2010 10:11 PM, Peter Geoghegan wrote: We changed 8.5 to 9.0 explicitly because doing so was good marketing, That's exactly how I see this as well. The current scheme allows for some flexibility for marketing purposes while still being self-consistent and logical in numbering. sarcasm And it allows us to have heated debates about whether or not the next release is worth a major version bump. /sarcasm Regards Markus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, Aug 21, 2010 at 1:00 PM, Greg Stark gsst...@mit.edu wrote: On Sat, Aug 21, 2010 at 4:29 AM, Sergio A. Kessler sergiokess...@gmail.com wrote: on every single planet of the universe, except the one called postgrearth, whose inhabitants breathe sql and eat messages from postgresql mailing lists... :-) most people I know, think 8.1 is just 8.0 with some fixes... Really? is Linux 2.6 just 2.5 with some fixes? Glibc 2.Was Windows 3.5 just 3.4 with some fixes? Gnome 2.28 just 2.27 with some fixes? really !, they don't have *any* idea of the version of the kernel, they know about redhat 4, redhat 5 and so on... glibc ? what is that ? is not something they use... :-) sure, we know better, but the common guy in the computer field, does not read every mailing list on earth... In fact perusing dpkg -l output the *only* software package I find that bumps the major version every single release is Emacs. It stands out as an outlier as soon as you say version 23 -- and that was despite a hiatus when version 18.59 was the newest release for years. imho, emacs does it rigth... regards, /sak -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
The current system give people the completely false impression that 7.0 and 7.4 are somehow similar. On what planet? on every single planet of the universe, except the one called postgrearth, whose inhabitants breathe sql and eat messages from postgresql mailing lists... :-) most people I know, think 8.1 is just 8.0 with some fixes... regards, /sak -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On 08/20/2010 09:04 PM, David E. Wheeler wrote: On Aug 20, 2010, at 12:02 PM, Greg Stark wrote: Again, it means the format would be consistent. Always three integers. Nice thing about Semantic Versions is that if you append any ASCII string to the third integer, it automatically means less than that integer. So I count three integers in both 9.0rc1 and 9.0beta4 No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one would *always* use X.Y.Z, with optional ASCII characters appended to Z to add meaning (including less than unadorned Z). hmm FWIW I would interpret something like 9.0.1B4 as the forth beta release for the first point release of the major release 9.0 bis seems stupid and is not anything we have done before. You could argue that 9.0.0B4 is the foourth beta for the first production release of 9.0 but I find the current naming much more reasonable... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 21, 2010, at 1:45 AM, Stefan Kaltenbrunner wrote: hmm FWIW I would interpret something like 9.0.1B4 as the forth beta release for the first point release of the major release 9.0 bis seems stupid and is not anything we have done before. It does't make sense for PostgreSQL, no. You could argue that 9.0.0B4 is the foourth beta for the first production release of 9.0 but I find the current naming much more reasonable... Yeah, it's just semantics, really. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, Aug 21, 2010 at 4:29 AM, Sergio A. Kessler sergiokess...@gmail.com wrote: on every single planet of the universe, except the one called postgrearth, whose inhabitants breathe sql and eat messages from postgresql mailing lists... :-) most people I know, think 8.1 is just 8.0 with some fixes... Really? is Linux 2.6 just 2.5 with some fixes? Glibc 2.Was Windows 3.5 just 3.4 with some fixes? Gnome 2.28 just 2.27 with some fixes? In fact perusing dpkg -l output the *only* software package I find that bumps the major version every single release is Emacs. It stands out as an outlier as soon as you say version 23 -- and that was despite a hiatus when version 18.59 was the newest release for years. Here is the Gnome project's description of what's new in 2.28 (over 2.26, the previous public release): The GNOME Project's focus on users and usability continues in GNOME 2.28 with its hundreds of bug fixes and user-requested improvements. The sheer number of enhancements makes it impossible to list every change and improvement made, but these notes aim to highlight some of the more exciting, user-oriented features in this release. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, 2010-08-21 at 17:00 +0100, Greg Stark wrote: On Sat, Aug 21, 2010 at 4:29 AM, Sergio A. Kessler sergiokess...@gmail.com wrote: on every single planet of the universe, except the one called postgrearth, whose inhabitants breathe sql and eat messages from postgresql mailing lists... :-) most people I know, think 8.1 is just 8.0 with some fixes... Really? is Linux 2.6 just 2.5 with some fixes? Glibc 2.Was Windows 3.5 just 3.4 with some fixes? Gnome 2.28 just 2.27 with some fixes? Thank you for this. It validates something that has been nagging me. Do you really think the majority of users even know what kernel they are running? They don't. They know they are running Ubuntu or Fedora. They probably know the version but they have no idea what version of the kernel that is being run. PostgreSQL is a user space project. Yes we have a solid core of -hackers but our wider use is a place where hackers don't exist. User space developers do. I.e; PHP people. Reminder, there was no Windows 3.4 or Windows 3.5. Yes it does matter. There was: 3.1x 3.11 for Workgroups Windows NT 3.1 Windows NT 3.5 Windows NT 4.0 (I am ignoring ME) Windows XP There was *NEVER* a Windows NT 4.0.x, there was Windows NT 4.0 SP2. The semantics are important. People mock Microsoft but except for some notable blunders (Windows ME, splurt) they are very, very good at getting mind share. Here is the Gnome project's description of what's new in 2.28 (over 2.26, the previous public release): Gnome is a bad example. People barely know if at all they are running Gnome. They are running Ubuntu. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
Joshua D. Drake j...@commandprompt.com writes: PostgreSQL is a user space project. Yes we have a solid core of -hackers but our wider use is a place where hackers don't exist. User space developers do. I.e; PHP people. This is utter nonsense. We're a database, not a desktop. People who even know what a database is, let alone program one, are sufficiently geeky to be aware of the usual conventions for software version numbering. Or at least to RTFM if they don't. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, Aug 21, 2010 at 5:51 PM, Joshua D. Drake j...@commandprompt.com wrote: There was *NEVER* a Windows NT 4.0.x, there was Windows NT 4.0 SP2. I'm not sure what you're point is here. There was a NT 4.0 followed by SP1 through SP6. followed by NT 5.0, 5.1, 5.2, 6.0, 6.1, and 7.0. They also had brand names 2000, XP, 2003, Vista, 7, etc -- is this model less confusing? The whole point here is that there is a pretty broad consensus across software projects that the first digit is for major releases that change the whole product character -- Linux 2.0, Samba 3.x, Libc 6, Even Windows 4 and Oracle 8. The second is for releases that add features, and the third digit is for minor releases. Our release numbering scheme is the same used by the vast majority of software packages. There are marketing pressures that cause version number inflation like Oracle 9i, 10g, 11g where regular releases are branded as huge improvements to warrant spending extra money on them. Sometimes the reverse happens and companies release regular releases and want to avoid bumping the number from a popular version. Things like Win 98 SP2 or Oracle 8i. But those are marketing pressures that large companies feel to deceive their users into misunderstanding what they're being sold. Open source projects have generally not felt pressures like that and have been able to just use regular version numbering schemes that users understand. Now we're getting the blowback from users confused by these marketing schemes who no longer understand how normal version number schemes work. There's no evidence that adopting marketing driven version numbering will confuse these people any less -- they're probably perpetually confused about software release engineerng -- and there's every reason to think that it would confuse the 99% of our users who are perfectly accustomed to software version numbering schemes much more to use an unusual scheme used only by a handful of other projects and (inconsistently) by big marketing departments. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, 2010-08-21 at 13:12 -0400, Tom Lane wrote: Joshua D. Drake j...@commandprompt.com writes: PostgreSQL is a user space project. Yes we have a solid core of -hackers but our wider use is a place where hackers don't exist. User space developers do. I.e; PHP people. This is utter nonsense. We're a database, not a desktop. No. Yes. Obviously. I was not comparing us to a desktop. I was stating that the people we are trying to reach are user space developers, like PHP people. People who even know what a database is, let alone program one, are sufficiently geeky to be aware of the usual conventions for software version numbering. Can and will are different things. Every barrier that we can lower without sacrificing the quality of our software, is a barrier that should be lowered. Period. If modifying the version numbering scheme helps even an ants inch, we should do it. Or at least to RTFM if they don't. If this were true, this thread wouldn't be as long as it is, nor would our mailing lists be anywhere near as busy as they are. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, Aug 21, 2010 at 03:34:35AM -, Greg Sabino Mullane wrote: It's possible that we're arguing for the sake of arguing No it's not! ;) Yes it is! ;) It's nice to be able to keep track of the major version number without running out of fingers (at least for a few more years) and it's nice to be able to bump the major version number when we do something to totally destabilize the tree^W^W^W^W^Wreally cool. Or at least, I think it's nice. Again, YMMV, IMHO, etc. If the Windows port was the primary justification for the 8.0 designation, and HS/SR are the justification for the 9.0 designation, what will 10.0 be? Therein lies the problem: our decision to do a major bump is inconsistent at best, and wildy confusing at worst. Does a new feature really constitute a major bump? Perhaps so, as with 9.0 SR/HS, but in that case there have been other times we should have bumped the major for some new feature and did not. What about major internal changes and libpq version bumps? You might think those would always be a major change, but they are not. We went from 7.2 to 7.3 without considering how major it is (hello, schemas!). What about end-user compatiblity? I sometimes suspect few hackers on this list realize how completely disruptive, annoying, and painful the removal of implicit casts was in 8.3. That would have been a major bump in my book at least. I think in the future we should consider lowering the bar for a major release, as it's better to err on that side. Disruptive to developers is one sufficient criterion. Another is does some big thing simply that would have been hard or impossible before. Previous things like dblink, schemas and CTEs, and upcoming things like synchronous replication, SQL/MED, parallel query, and (of course ;) writeable CTEs, would qualify under that second. Open for discussion would be features like Can spit out, on demand, any subset of the dependency graph for an object. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, Aug 21, 2010 at 5:51 PM, Joshua D. Drake j...@commandprompt.com wrote: PostgreSQL is a user space project. Yes we have a solid core of -hackers but our wider use is a place where hackers don't exist. User space developers do. I.e; PHP people. Uhm http://en.wikipedia.org/wiki/PHP#Release_history The current release of PHP is 5.3.3 -- ie, the third patch release of the third regular release of PHP5 -- the fifth major rewrite of the engine and language. They use exactly the same model we use and virtually every other software package every uses unti the marketing department gets ahold of it and confuses things. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, Aug 21, 2010 at 6:24 PM, Greg Stark gsst...@mit.edu wrote: I'm not sure what you're point is here. Argh! This thread is almost enough to make me believe in adding recalls to smtp. I can't even blame this one on my flaky keyboard this time. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, 2010-08-21 at 18:24 +0100, Greg Stark wrote: On Sat, Aug 21, 2010 at 5:51 PM, Joshua D. Drake j...@commandprompt.com wrote: There was *NEVER* a Windows NT 4.0.x, there was Windows NT 4.0 SP2. I'm not sure what you're point is here. There was a NT 4.0 followed by SP1 through SP6. followed by NT 5.0, 5.1, 5.2, 6.0, 6.1, and 7.0. They also had brand names 2000, XP, 2003, Vista, 7, etc -- is this model less confusing? Yeah sorry. I kind of went down a path without completing the thought process. There was no NT 5.0, 5.1 etc... There may have been an internal name, an engineers name, or heck possibly even if you did help about it would mention 5.0 (I don't actually know). However, the users never new them as those. Period. Which is what I am getting at. Our new and less technical users are confused about whether 8.1 and 8.2 are 8.0 SP1 and 8.0 SP2. Which they clearly aren't. The whole point here is that there is a pretty broad consensus across software projects that the first digit is for major releases that change the whole product character -- Linux 2.0, Samba 3.x, Libc 6, All three of those are irrelevant to this conversation. Users don't run Linux 2.0. They run Ubuntu, Fedora or SUSE. I can easily on a weekly basis run into a customer, or external community user that says, I am running PostgreSQL 8. They will actually be running, 8.0, 8.1, 8.2, 8.3 or 8.4. Yes, a good number of more technical, or those who have been in the community longer have figured it out Let's make this simple: Q. Do we have a problem? A. Some of our contributors, even some very experienced contributors feel we do. Q. What is the problem we are trying to solve? A. That users, especially those that are less technical are confused by our versioning system. Q. How do we solve that problem? A. ... Q. Does the presented solution create a new problem that must be solved? A. ... It would be great everyone would stop arguing semantics (myself included) and just attempt to solve the problem. Education isn't going to cut it, we have been educating for almost 15 years. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, 2010-08-21 at 18:35 +0100, Greg Stark wrote: On Sat, Aug 21, 2010 at 6:24 PM, Greg Stark gsst...@mit.edu wrote: I'm not sure what you're point is here. Argh! This thread is almost enough to make me believe in adding recalls to smtp. I can't even blame this one on my flaky keyboard this time. Hahahahaha. Yeah I think we are spinning at this point. I posted a simple, problem we are trying to solve email. If we can do that, great. If not we are just wasting bandwidth. Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, Aug 21, 2010 at 6:37 PM, Joshua D. Drake j...@commandprompt.com wrote: Q. Do we have a problem? A. Some of our contributors, even some very experienced contributors feel we do. Q. What is the problem we are trying to solve? A. That users, especially those that are less technical are confused by our versioning system. Q. How do we solve that problem? A. ... Sorry, but this is all a logical fallacy. There will always be a percentage of people who are confused. The question is which scheme results in the least confusion and communicates the most information. Following industry standard practice is the best way to minimize that confusion. If we adopt a different scheme then it might be clearer to beginners but be confusing and unhelpful to everyone else. It'll look like we're doing a major rewrite every year and there's no way to tell which releases are major changes and which are just annual releases. Frankly I think we've been bumping version numbers too often. It's a consequence of the insane pace of development we've had. Adding PITR in 8.0 was a pretty major step and hot standby in 9.0 will be big too. But we should be limiting the first digit for Perl 6 scale changes, not just features that are really really cool. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
Or at least to RTFM if they don't. If this were true, this thread wouldn't be as long as it is, nor would our mailing lists be anywhere near as busy as they are. This thread is as long as it is principally because people generally bikeshed about things that are easy to understand, and are fun to have an opinion about. Frankly I think we've been bumping version numbers too often. It's a consequence of the insane pace of development we've had. Adding PITR in 8.0 was a pretty major step and hot standby in 9.0 will be big too. But we should be limiting the first digit for Perl 6 scale changes, not just features that are really really cool. While I generally agree with your views about versioning conventions, if we did that, we'd probably never bump the major version number. As far as I'm aware, Postgres has never had such radical changes in a single release, that broke compatibility to such an extent. Also, while we aren't subject to the same commercial pressures as the proprietary vendors, I don't think that we can afford to not have our versioning conventions informed by marketing concerns to any extent. We changed 8.5 to 9.0 explicitly because doing so was good marketing, and also because of HS/SR (plus we wanted to hint at the fact that 9.0 might not be the most stable release we've had), and I'm inclined to agree with that. -- Regards, Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
I don´t have any problem with PostgreSQL version numbering, to the contrary. The only thing I didn´t like was Postgres95, but I didn´t use Pg then. But since then it´s _consistent_ and I really appreciate that. I could live with, say, version 9.12.0 in a dozend years. I accept the alpha, beta or RC extensions. I don´t like the M$ way: Why is WinWord 2 followed by WinWord 7? Why sometimes a number, then a name like Win98 followed by ME. Marketing? What´s the next idea of their marketing departmenr? May be Windows Baobao because the chinese market is really important? I don´t want to compare me or my users with yours. Most of my users know exactly one thing about the data base: When it´s NOT working. That´s all they care for. Working, not numbering. My users are all small and mid size enterprises, with less than 150 employees. They are just users and hire me as generalist, as developer, administrator, DBA, hot line and the one to cope with their inability to RTFM in one person. Usually they are satisfied PostgreSQL users without knowing what it is or what it does. It´s just - sorry for that - somewhere in the background. Like my MTA, which is ehem... duh, have to look for. Wolfgang
[HACKERS] Version Numbering
Hackers, A while ago, I asked if .0 releases could be versioned with three digits instead of two. That is, it would be 8.4.0 instead of 8.4. This is to make the format consistent with maintenance releases (8.4.1, etc.). I thought this was generally agreed upon, but maybe not, because I just went to build the latest 9.0 beta and saw that the version number is 9.0beta4. Would it be possible to *always* use three integers? So the next release would be 9.0.0beta5 or 9.0.0rc1? In addition to being more consistent, it also means that PostgreSQL would be adhering to Semantic Versioning (http://semver.org/), which is a very simple format that's internally consistent. I'm planning to require semantic versioning for PGXN, and it'd be nice if the core could do the same thing (it will make it nicer for specifying dependencies on core contrib modules, for example). Thanks, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 11:12:56AM -0700, David Wheeler wrote: Hackers, A while ago, I asked if .0 releases could be versioned with three digits instead of two. That is, it would be 8.4.0 instead of 8.4. This is to make the format consistent with maintenance releases (8.4.1, etc.). I thought this was generally agreed upon, but maybe not, because I just went to build the latest 9.0 beta and saw that the version number is 9.0beta4. Would it be possible to *always* use three integers? So the next release would be 9.0.0beta5 or 9.0.0rc1? In addition to being more consistent, it also means that PostgreSQL would be adhering to Semantic Versioning (http://semver.org/), which is a very simple format that's internally consistent. I'm planning to require semantic versioning for PGXN, and it'd be nice if the core could do the same thing (it will make it nicer for specifying dependencies on core contrib modules, for example). +1 for three-number versions...well, until we really see the light and go to two-number versions. 8.3 and 8.4 are different enough that they shouldn't even mildly appear the same, for example. Cheers, David (Oh, how silly! You actually want Frobozz 3.1.4.1.5.2.6, not 3.1.4.1.5.2.5!). -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 20, 2010, at 11:34 AM, David Fetter wrote: +1 for three-number versions...well, until we really see the light and go to two-number versions. 8.3 and 8.4 are different enough that they shouldn't even mildly appear the same, for example. No idea what you mean by that, but generally it's a bad idea to switch from dotted-integer version numbers and numeric version numbers. See Perl (Quel désastre!). Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
David E. Wheeler da...@kineticode.com writes: A while ago, I asked if .0 releases could be versioned with three digits instead of two. That is, it would be 8.4.0 instead of 8.4. We've been doing that for some time, no? A quick look at the CVS history shows that 8.0.0 and up were tagged that way. This is to make the format consistent with maintenance releases (8.4.1, etc.). I thought this was generally agreed upon, but maybe not, because I just went to build the latest 9.0 beta and saw that the version number is 9.0beta4. .0 is for releases, not betas. I see no need for an extra number in beta versions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 20, 2010, at 11:40 AM, Tom Lane wrote: David E. Wheeler da...@kineticode.com writes: A while ago, I asked if .0 releases could be versioned with three digits instead of two. That is, it would be 8.4.0 instead of 8.4. We've been doing that for some time, no? A quick look at the CVS history shows that 8.0.0 and up were tagged that way. Ah, good for the final release. This is to make the format consistent with maintenance releases (8.4.1, etc.). I thought this was generally agreed upon, but maybe not, because I just went to build the latest 9.0 beta and saw that the version number is 9.0beta4. .0 is for releases, not betas. I see no need for an extra number in beta versions. Again, it means the format would be consistent. Always three integers. Nice thing about Semantic Versions is that if you append any ASCII string to the third integer, it automatically means less than that integer. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 11:36:55AM -0700, David Wheeler wrote: On Aug 20, 2010, at 11:34 AM, David Fetter wrote: +1 for three-number versions...well, until we really see the light and go to two-number versions. 8.3 and 8.4 are different enough that they shouldn't even mildly appear the same, for example. No idea what you mean by that, but generally it's a bad idea to switch from dotted-integer version numbers and numeric version numbers. See Perl (Quel désastre!). I'm thinking that after 9.0, the first release of the next major version should be 10.0, and the one after that, 11.0, etc., etc. The current system give people the completely false impression that 7.0 and 7.4 are somehow similar. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 20, 2010, at 11:47 AM, David Fetter wrote: No idea what you mean by that, but generally it's a bad idea to switch from dotted-integer version numbers and numeric version numbers. See Perl (Quel désastre!). I'm thinking that after 9.0, the first release of the next major version should be 10.0, and the one after that, 11.0, etc., etc. Oh. Good luck with that. I disagree, FWIW. The current system give people the completely false impression that 7.0 and 7.4 are somehow similar. On what planet? Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 7:34 PM, David Fetter da...@fetter.org wrote: +1 for three-number versions...well, until we really see the light and go to two-number versions. 8.3 and 8.4 are different enough that they shouldn't even mildly appear the same, for example. You realize if we did that 9.0 would be version 18? David (Oh, how silly! You actually want Frobozz 3.1.4.1.5.2.6, not 3.1.4.1.5.2.5!). So eventually you end up with the same problem. Oh, you wanted version 117 not 116! -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 7:42 PM, David E. Wheeler da...@kineticode.com wrote: Again, it means the format would be consistent. Always three integers. Nice thing about Semantic Versions is that if you append any ASCII string to the third integer, it automatically means less than that integer. So I count three integers in both 9.0rc1 and 9.0beta4 -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 20, 2010, at 12:02 PM, Greg Stark wrote: Again, it means the format would be consistent. Always three integers. Nice thing about Semantic Versions is that if you append any ASCII string to the third integer, it automatically means less than that integer. So I count three integers in both 9.0rc1 and 9.0beta4 No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one would *always* use X.Y.Z, with optional ASCII characters appended to Z to add meaning (including less than unadorned Z). Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
David E. Wheeler da...@kineticode.com writes: On Aug 20, 2010, at 12:02 PM, Greg Stark wrote: So I count three integers in both 9.0rc1 and 9.0beta4 No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one would *always* use X.Y.Z, with optional ASCII characters appended to Z to add meaning (including less than unadorned Z). Well, I for one will fiercely resist adopting any such standard, because it's directly opposite to the way that RPM will sort such version numbers. Apparently whoever wrote Semantic Versioning didn't bother to inquire into existing practice. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 20, 2010, at 12:15 PM, Tom Lane wrote: No, I mean 9.0.0beta4. If we were to adopt the Semantic Versioning spec, one would *always* use X.Y.Z, with optional ASCII characters appended to Z to add meaning (including less than unadorned Z). Well, I for one will fiercely resist adopting any such standard, because it's directly opposite to the way that RPM will sort such version numbers. Which is how? Apparently whoever wrote Semantic Versioning didn't bother to inquire into existing practice. Tom Preston-Warner of GitHub fame. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
+1 for Tom's post. -- Devrim GÜNDÜZ PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz 20.Ağu.2010 tarihinde 21:40 saatinde, Tom Lane t...@sss.pgh.pa.us şunları yazdı: David E. Wheeler da...@kineticode.com writes: A while ago, I asked if .0 releases could be versioned with three digits instead of two. That is, it would be 8.4.0 instead of 8.4. We've been doing that for some time, no? A quick look at the CVS history shows that 8.0.0 and up were tagged that way. This is to make the format consistent with maintenance releases (8.4.1, etc.). I thought this was generally agreed upon, but maybe not, because I just went to build the latest 9.0 beta and saw that the version number is 9.0beta4. .0 is for releases, not betas. I see no need for an extra number in beta versions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
20.Ağu.2010 tarihinde 21:47 saatinde, David Fetter da...@fetter.org şunları yazdı: The current system give people the completely false impression that 7.0 and 7.4 are somehow similar. Well, I do find PostgreSQL versioning policy very good, which is pretty much similar to Linux. For me, 7.x are similar. Remember why we jumped from 7.5 to 8.0 or from 8.5 to 9.0. Cheers, -- Devrim GÜNDÜZ PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 20, 2010, at 12:21 PM, Devrim GÜNDÜZ wrote: +1 for Tom's post. 20.Ağu.2010 tarihinde 21:40 saatinde, Tom Lane t...@sss.pgh.pa.us şunları yazdı: .0 is for releases, not betas. I see no need for an extra number in beta versions. Yes, well, it's still implicit, isn't it? David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
* David E. Wheeler (da...@kineticode.com) wrote: On Aug 20, 2010, at 12:21 PM, Devrim GÜNDÜZ wrote: +1 for Tom's post. 20.Ağu.2010 tarihinde 21:40 saatinde, Tom Lane t...@sss.pgh.pa.us şunları yazdı: .0 is for releases, not betas. I see no need for an extra number in beta versions. Yes, well, it's still implicit, isn't it? It's still useless garbage.. Sorry, I'm w/ Tom on this one. THanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Version Numbering
David E. Wheeler da...@kineticode.com wrote: .0 is for releases, not betas. I see no need for an extra number in beta versions. Yes, well, it's still implicit, isn't it? Not the way I read it. If we had a development cycle which resulted in 8.4.5beta4, then you would have a point. We don't. Now, if you wanted to argue that it would be better to use 9.0.beta4 than 9.0beta4, that might be defensible. I think I like that better; but I'm not inclined to think the difference is worth the pain of changing an established convention. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
Yes, well, it's still implicit, isn't it? But the last .0 in 9.0.0 is the patch level, effectively. This makes that .0 inappropriate for betas; the beta number is the patch level, i.e. 9.0.beta4. It doesn't make any sense to have a 9.0.0beta4, since we're never going to have a 9.0.2beta4. The betas are pre-.0. Maybe we should have 9.0.(-3) instead. Or 8.9.97? ;-) -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
20.Ağu.2010 tarihinde 23:03 saatinde, Josh Berkus j...@agliodbs.com şunları yazdı: The betas are pre-.0. Maybe we should have 9.0.(-3) instead. Or 8.9.97? ;-) This is pretty much what Fedora does actually :-) -- Devrim GÜNDÜZ PostgreSQL DBA @ Akinon/Markafoni, Red Hat Certified Engineer devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 07:59:55PM +0100, Greg Stark wrote: On Fri, Aug 20, 2010 at 7:34 PM, David Fetter da...@fetter.org wrote: +1 for three-number versions...well, until we really see the light and go to two-number versions. 8.3 and 8.4 are different enough that they shouldn't even mildly appear the same, for example. You realize if we did that 9.0 would be version 18? Yes. And? David (Oh, how silly! You actually want Frobozz 3.1.4.1.5.2.6, not 3.1.4.1.5.2.5!). So eventually you end up with the same problem. Oh, you wanted version 117 not 116! Assuming wild optimism, namely that we release a major version each year on the exact same date, that will become a problem *long* after no one in this discussion is still involved with the project. I'm OK with deferring this to future generations. Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 11:48:12AM -0700, David Wheeler wrote: On Aug 20, 2010, at 11:47 AM, David Fetter wrote: No idea what you mean by that, but generally it's a bad idea to switch from dotted-integer version numbers and numeric version numbers. See Perl (Quel désastre!). I'm thinking that after 9.0, the first release of the next major version should be 10.0, and the one after that, 11.0, etc., etc. Oh. Good luck with that. I disagree, FWIW. The current system give people the completely false impression that 7.0 and 7.4 are somehow similar. On what planet? We're using Postgre 8 See also all the flocks of tools that claim to support Postgres 8 Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
David E. Wheeler da...@kineticode.com writes: On Aug 20, 2010, at 12:15 PM, Tom Lane wrote: Well, I for one will fiercely resist adopting any such standard, because it's directly opposite to the way that RPM will sort such version numbers. Which is how? 9.0.0 is less than 9.0.0anything. Unless you wire some specific knowledge of semantics of particular letter-strings into the comparison algorithm, it's difficult to come to another decision, IMO. BTW, 9.0.0 is also less than 9.0.0.anything ... so sticking another dot in there wouldn't help. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 David Wheeler: No idea what you mean by that, but generally it's a bad idea to switch from dotted-integer version numbers and numeric version numbers. See Perl (Quel dsastre!). Yeah, I think Perl is a prime example of how NOT to handle version numbering. :) I think we got it right the first time. David Fetter: We're using Postgre 8 See also all the flocks of tools that claim to support Postgres 8 Flocks? Handful at best, and no reason we should be catering to their inaccuracies. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 201008201713 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkxu8NkACgkQvJuQZxSWSsgNVACfYko/YC7SOlMXpavO7JXWSZhp i7QAoKmPKvNlASLAYfimtnrpg0lk82vh =aWSL -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
* Tom Lane t...@sss.pgh.pa.us [100820 17:10]: BTW, 9.0.0 is also less than 9.0.0.anything ... so sticking another dot in there wouldn't help. Debian's packaging versions work around this with the special ~ character, which they define as sorting *before* nothing, meaning 8.4~beta1 8.4 8.4.0 8.4extra See the deb-version man page for details, a nice convinenct, but yes, a special cased rule... But at least it's wildly used ;-) a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Version Numbering
On Fri, 2010-08-20 at 21:17 +, Greg Sabino Mullane wrote: David Fetter: We're using Postgre 8 See also all the flocks of tools that claim to support Postgres 8 Flocks? Handful at best, and no reason we should be catering to their inaccuracies. Depends on the goal. If our goal is to continue to add confusion to the masses of users we have, you are correct. If our goal is to simplify the ability for a user to accurately understand the version of PostgreSQL they are running, then you are wrong. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 20, 2010, at 2:10 PM, Tom Lane wrote: 9.0.0 is less than 9.0.0anything. Unless you wire some specific knowledge of semantics of particular letter-strings into the comparison algorithm, it's difficult to come to another decision, IMO. That's what Semantic versions do. From the spec's #3: A special version number MAY be denoted by appending an arbitrary string immediately following the patch version. The string MUST be comprised of only alphanumerics plus dash [0-9A-Za-z-] and MUST begin with an alpha character [A-Za-z]. Special versions satisfy but have a lower precedence than the associated normal version. Precedence SHOULD be determined by lexicographic ASCII sort order. For instance: 1.0.0beta1 1.0.0beta2 1.0.0. I'm comfortable with this because it's consistent with what people expect when they read a version number. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 1:48 PM, David E. Wheeler da...@kineticode.com wrote: On Aug 20, 2010, at 11:47 AM, David Fetter wrote: The current system give people the completely false impression that 7.0 and 7.4 are somehow similar. On what planet? Look at other DBMSes: Oracle: 8i, 9i, 10g, 11g Informix 9, 10, 11 MS SQL Server 7, 2000, 2005, 2008 note the lack of dotes (and even if they actually have dots, those are minor versions). is not only confusing but make people think we are somehow behind the others... someone actually told me that Oracle is in version 11 we only in version 8 so Oracle should have more features... no that i follow that reasoning but... -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 04:41:20PM -0500, Jaime Casanova wrote: On Fri, Aug 20, 2010 at 1:48 PM, David E. Wheeler da...@kineticode.com wrote: On Aug 20, 2010, at 11:47 AM, David Fetter wrote: The current system give people the completely false impression that 7.0 and 7.4 are somehow similar. On what planet? Look at other DBMSes: Oracle: 8i, 9i, 10g, 11g Informix 9, 10, 11 MS SQL Server 7, 2000, 2005, 2008 note the lack of dotes (and even if they actually have dots, those are minor versions). Some people dote on dots. is not only confusing but make people think we are somehow behind the others... someone actually told me that Oracle is in version 11 we only in version 8 so Oracle should have more features... no that i follow that reasoning but... This one goes up to 11! ;) Cheers, David. -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova ja...@2ndquadrant.com wrote: Look at other DBMSes: Oracle: 8i, 9i, 10g, 11g Informix 9, 10, 11 MS SQL Server 7, 2000, 2005, 2008 note the lack of dotes (and even if they actually have dots, those are minor versions). So your proposal is that we name the next release of Postres 9i? I don't think looking at some of the most industry worst practices driven by marketing goals unconnected with the product features is going to help us in any way. In any case those are all marketing brand names. The actual releases do in fact have real version numbers and no, they aren't all minor releases. Oracle 8i was 8.1.x which was indeed a major release over 8.0. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark gsst...@mit.edu wrote: On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova ja...@2ndquadrant.com wrote: Look at other DBMSes: Oracle: 8i, 9i, 10g, 11g Informix 9, 10, 11 MS SQL Server 7, 2000, 2005, 2008 note the lack of dotes (and even if they actually have dots, those are minor versions). So your proposal is that we name the next release of Postres 9i? well, i'm not proposing anything... just showing that our numbering scheme *is* confusing In any case those are all marketing brand names. The actual releases do in fact have real version numbers and no, they aren't all minor releases. Oracle 8i was 8.1.x which was indeed a major release over 8.0. Maybe we can give marketing brand names to every new version so people is not confused by numbers... -- Jaime Casanova www.2ndQuadrant.com Soporte y capacitación de PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 10:55 PM, Jaime Casanova ja...@2ndquadrant.com wrote: In any case those are all marketing brand names. The actual releases do in fact have real version numbers and no, they aren't all minor releases. Oracle 8i was 8.1.x which was indeed a major release over 8.0. Maybe we can give marketing brand names to every new version so people is not confused by numbers... I can't tell whether you're being sarcastic or not. The whole point of those marketing names *is* to confuse users. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 20, 2010, at 5:55 PM, Jaime Casanova ja...@2ndquadrant.com wrote: On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark gsst...@mit.edu wrote: On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova ja...@2ndquadrant.com wrote: Look at other DBMSes: Oracle: 8i, 9i, 10g, 11g Informix 9, 10, 11 MS SQL Server 7, 2000, 2005, 2008 note the lack of dotes (and even if they actually have dots, those are minor versions). So your proposal is that we name the next release of Postres 9i? well, i'm not proposing anything... just showing that our numbering scheme *is* confusing In any case those are all marketing brand names. The actual releases do in fact have real version numbers and no, they aren't all minor releases. Oracle 8i was 8.1.x which was indeed a major release over 8.0. Maybe we can give marketing brand names to every new version so people is not confused by numbers... Ah, yes. Because it's so intuitive that Windows 7 comes after Windows 95... :-) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On 20 August 2010 23:10, Robert Haas robertmh...@gmail.com wrote: On Aug 20, 2010, at 5:55 PM, Jaime Casanova ja...@2ndquadrant.com wrote: On Fri, Aug 20, 2010 at 4:48 PM, Greg Stark gsst...@mit.edu wrote: On Fri, Aug 20, 2010 at 10:41 PM, Jaime Casanova ja...@2ndquadrant.com wrote: Look at other DBMSes: Oracle: 8i, 9i, 10g, 11g Informix 9, 10, 11 MS SQL Server 7, 2000, 2005, 2008 note the lack of dotes (and even if they actually have dots, those are minor versions). So your proposal is that we name the next release of Postres 9i? well, i'm not proposing anything... just showing that our numbering scheme *is* confusing In any case those are all marketing brand names. The actual releases do in fact have real version numbers and no, they aren't all minor releases. Oracle 8i was 8.1.x which was indeed a major release over 8.0. Maybe we can give marketing brand names to every new version so people is not confused by numbers... Ah, yes. Because it's so intuitive that Windows 7 comes after Windows 95... :-) ...Robert A colleague of mine wrote this which might be of interest, and it mentions both Windows and PostgreSQL: http://rwec.co.uk/blog/2010/02/golden-rules-of-version-naming/ -- Thom Brown Registered Linux user: #516935 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, 2010-08-20 at 18:10 -0400, Robert Haas wrote: Maybe we can give marketing brand names to every new version so people is not confused by numbers... Ah, yes. Because it's so intuitive that Windows 7 comes after Windows 95... :-) Not really a comparable argument. I find it interesting that people are making logical arguments about something that is clearly not in the logical realm. This is marketing people. Windows 7 works because it is than Windows Vista. It sounds, looks and feels greater. It also certainly doesn't hurt that they have billions for marketing. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
Not really a comparable argument. I find it interesting that people are making logical arguments about something that is clearly not in the logical realm. This is marketing people. Then why are we discussing it on -hackers? -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, 2010-08-20 at 15:41 -0700, Josh Berkus wrote: Not really a comparable argument. I find it interesting that people are making logical arguments about something that is clearly not in the logical realm. This is marketing people. Then why are we discussing it on -hackers? Good point :D -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Then why are we discussing it on -hackers? Because you will need buy in from the hackers if you ever want to do something as radical as change to a two-number, one dot system (or some the slightly less radical earlier suggestions). For the record, I'm with Tom on this: -1 to any changes. I do like the Ubuntu/Debian way of naming the releases with some sort of non-numeric name though. :) - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 201008202036 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkxvH+EACgkQvJuQZxSWSshfdwCgxutLw7s2o225qvhKRXeJzvwo xVgAnAoptFyCTKljX52q7RTsGElDHswE =yS2/ -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Flocks? Handful at best, and no reason we should be catering to their inaccuracies. Depends on the goal. If our goal is to continue to add confusion to the masses of users we have, you are correct. If our goal is to simplify the ability for a user to accurately understand the version of PostgreSQL they are running, then you are wrong. Are we adding confusion? Do you have any proof to back up that assertion? I'm pretty sure the masses can handle the fact that 9.1.x is going to come after 9.0.x, and that 9.0.1 is an bug fix for 9.0.0. True, we don't always have the best track record for bumping major releases. (ponders) Hmmm...I'm rethinking my immediate rejection of the idea now. 7.3 to 7.4 should have been 7.3 to 8.0. Certainly it was more major than 8.0 to 8.1 was, for example. Consider me a very weak -1 and open to persuasion. :) - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 201008202130 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkxvLGQACgkQvJuQZxSWSsjIoQCfY4ANKov5TV/PDV+mc0Rhda5O wskAoMjZ4y9t+VOlP+84NMfz7Ws1aNVV =qRMV -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Look at other DBMSes: Oracle: 8i, 9i, 10g, 11g Informix 9, 10, 11 MS SQL Server 7, 2000, 2005, 2008 is not only confusing but make people think we are somehow behind the others... someone actually told me that Oracle is in version 11 we only in version 8 so Oracle should have more features... no that i follow that reasoning but... Well by that reasoning SQL Server 2008 is a quantum leap ahead of Oracle! Frankly, that 'someone' should be hit hard with a clue stick and be forced to keep 50 feet away from all computers. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 201008202135 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkxvLZAACgkQvJuQZxSWSsjFcQCeMQX9fQcLZVv6q1wssFIsIMQE INAAoJPEsMRsezdT2bAWP8xLZ7wSpxvh =yKn1 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, 2010-08-21 at 01:31 +, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Flocks? Handful at best, and no reason we should be catering to their inaccuracies. Depends on the goal. If our goal is to continue to add confusion to the masses of users we have, you are correct. If our goal is to simplify the ability for a user to accurately understand the version of PostgreSQL they are running, then you are wrong. Are we adding confusion? Do you have any proof to back up that assertion? I'm pretty sure the masses can handle the fact that 9.1.x is going to come after 9.0.x, and that 9.0.1 is an bug fix for 9.0.0. As I said previously. I am constantly educated new and old customers on proper versioning. I *know* I am not the only one that has this problem. True, we don't always have the best track record for bumping major releases. (ponders) Hmmm...I'm rethinking my immediate rejection of the idea now. 7.3 to 7.4 should have been 7.3 to 8.0. Certainly it was more major than 8.0 to 8.1 was, for example. Consider me a very weak -1 and open to persuasion. :) Are we losing something by going to a notably simpler scheme of versioning? Is there a problem we are creating? Are we arguing for the sake of arguing? Sincerely, Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Sat, 2010-08-21 at 01:36 +, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Look at other DBMSes: Oracle: 8i, 9i, 10g, 11g Informix 9, 10, 11 MS SQL Server 7, 2000, 2005, 2008 is not only confusing but make people think we are somehow behind the others... someone actually told me that Oracle is in version 11 we only in version 8 so Oracle should have more features... no that i follow that reasoning but... Well by that reasoning SQL Server 2008 is a quantum leap ahead of Oracle! Do we really want to have that argument :P JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering http://twitter.com/cmdpromptinc | http://identi.ca/commandprompt -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 20, 2010, at 5:38 PM, Greg Sabino Mullane wrote: Then why are we discussing it on -hackers? Because you will need buy in from the hackers if you ever want to do something as radical as change to a two-number, one dot system (or some the slightly less radical earlier suggestions). For the record, I'm with Tom on this: -1 to any changes. It's already a three-integer system for non-dev/alpha/rc releases. So I think it's fine the way it is (and easy enough to convert to semantic versions for comparative purposes, if necessary). So: WORMS: Back in the can! Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 2:12 PM, David E. Wheeler da...@kineticode.com wrote: Would it be possible to *always* use three integers? So the next release would be 9.0.0beta5 or 9.0.0rc1? In addition to being more consistent, it also means that PostgreSQL would be adhering to Semantic Versioning (http://semver.org/), which is a very simple format that's internally consistent. I'm planning to require semantic versioning for PGXN, and it'd be nice if the core could do the same thing (it will make it nicer for specifying dependencies on core contrib modules, for example). One thing that may be worth noting here is that even if we implemented this policy (and the consensus seems to be against it at the moment), we wouldn't be in compliance with semantic versioning, because our use of the first two components of the version number does not match that specification, and we aren't likely to make them match in the future. What that would mean is that certain kinds of changes would FORCE us to bump the major revision, and by historical precedent, pretty much every release cycle would have some. I've occasionally thought that it would be interesting to have something in between point releases and major releases, where, perhaps, we would implement changes that are more than what we'd allow for a minor version bump but nothing too invasive; and then use major releases for the real big stuff. But the problem with this is that it would greatly complicate development and testing and I think in the end we'd end up with a less reliable product and a lot more arguing about which branches things went into. I think the semantic versioning approach makes sense for libraries, but it is not too clear to me that it makes sense for other kinds of applications. YMMV, of course. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Aug 20, 2010, at 7:49 PM, Robert Haas wrote: I think the semantic versioning approach makes sense for libraries, but it is not too clear to me that it makes sense for other kinds of applications. YMMV, of course. Yeah, I'm more concerned about determining dependencies in extensions and core than I am why the various parts of version numbers are incremented. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
On Fri, Aug 20, 2010 at 10:43 PM, Joshua D. Drake j...@commandprompt.com wrote: True, we don't always have the best track record for bumping major releases. (ponders) Hmmm...I'm rethinking my immediate rejection of the idea now. 7.3 to 7.4 should have been 7.3 to 8.0. Certainly it was more major than 8.0 to 8.1 was, for example. Consider me a very weak -1 and open to persuasion. :) Are we losing something by going to a notably simpler scheme of versioning? Is there a problem we are creating? Are we arguing for the sake of arguing? It's possible that we're arguing for the sake of arguing, but it's so much easier to have an opinion on version numbering than to have an opinion on how to fix dependency problems in parallel restore. So maybe we're all just letting off some steam. With respect to simplifying the version numbering schema, I kind of like the one we have, nonwithstanding the problems it creates (namely, that people think 8.3.0 to 8.4.0 is a smaller change than it really is; for some reason, they also tend to think 8.4.0 to 8.4.1 is a bigger change than it really is; and of course they also think that 8.1.0 to 8.2.0 is the same size change as 8.2.0 to 8.3.0, which isn't true either). It's nice to be able to keep track of the major version number without running out of fingers (at least for a few more years) and it's nice to be able to bump the major version number when we do something to totally destabilize the tree^W^W^W^W^Wreally cool. Or at least, I think it's nice. Again, YMMV, IMHO, etc. If the Windows port was the primary justification for the 8.0 designation, and HS/SR are the justification for the 9.0 designation, what will 10.0 be? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Version Numbering
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 It's possible that we're arguing for the sake of arguing No it's not! ;) It's nice to be able to keep track of the major version number without running out of fingers (at least for a few more years) and it's nice to be able to bump the major version number when we do something to totally destabilize the tree^W^W^W^W^Wreally cool. Or at least, I think it's nice. Again, YMMV, IMHO, etc. If the Windows port was the primary justification for the 8.0 designation, and HS/SR are the justification for the 9.0 designation, what will 10.0 be? Therein lies the problem: our decision to do a major bump is inconsistent at best, and wildy confusing at worst. Does a new feature really constitute a major bump? Perhaps so, as with 9.0 SR/HS, but in that case there have been other times we should have bumped the major for some new feature and did not. What about major internal changes and libpq version bumps? You might think those would always be a major change, but they are not. We went from 7.2 to 7.3 without considering how major it is (hello, schemas!). What about end-user compatiblity? I sometimes suspect few hackers on this list realize how completely disruptive, annoying, and painful the removal of implicit casts was in 8.3. That would have been a major bump in my book at least. I think in the future we should consider lowering the bar for a major release, as it's better to err on that side. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 201008202330 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkxvSS0ACgkQvJuQZxSWSsjQ0QCfW/2l065L0XEO6kmnARpjgqJ5 t2EAn3xM8w5f5xmHl3EZAmXhxXFpEREo =/CYr -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
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
[HACKERS] 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
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
