Posted by
michael
on from the some-data-loss-inevitable dept.
ulrikp writes "Swedish MySQL AB, makers of the MySQL database, have released an Alpha-version of their flagship, dubbed MySQL 5.0.0. The changesinclude basic support for SQL-99 stored procedures. Please note: Despite the version number, this is an Alpha release, and not for general consumption."
In the spirit of the interesting compatibility version numbering post, informative version numbering is straightforward. Every version of software should be go through alpha, beta and release versions, for each change. When starting to edit the source code, increment the version number first. The number to increment, whether.., is determined by kind of compatibility the change will discard from the previous version: major=GUI/features, minor = data formats / APIs, build/patch = bugfixes. Once the number is first incremented, it is an ALPHA version, for testing/revision within the group (even of one person) that has developed it (any designers or programmers). Once alpha testing is complete within the developer group, whose preconceptions influence their testing, it is a BETA version, for testing outside of the developer group (customers, end users, random taste tests). Once beta testing/revision is complete, when all revision is complete, it is a RELEASE version, for another round of idiot-check retesting, usually by the release team testing with the packaging and distribution tools, with marketdroids given a more serious voice, when they take responsibility for unleashing it on the market. When alpha, beta or release phase revisions change compatibility with the previous version's GUI/features or data formats / APIs, the major or minor version number, respectively, is incremented, and it goes back to alpha testing. So an app might have version numbering like:
The versions released would be known only as 2.3, 2.3.1, and 2.4.5. 2.3 would be binary compatible with 2.3.1, and the same GUI and features, but 2.4.5 would only look and feel like 2.3, without binary compatibility (either data formats or APIs). This scheme makes version numbers actually useful, to consumers, new developers, and even automated interoperability systems (a la apt-get). It also offers an incentive to keep version numbers lower, as higher numbers reflect more changes (get it right the first time). At least in the minor and build/patch numbers. Most importantly, it reflects a reasonable test/revise/release discipline. So the numbers are the tail, wagged by the dog.
--
--
make install -not war
Re:For all the PostgreSQL zealots out there...
by
jadavis
·
· Score: 4, Insightful
I have been looking for a long time for a MySQL person to actually say something that bugged them about PostgreSQL, and why they couldn't use it.
When I started using postgresql, at 6.5.3, it was deficient in many ways. Advocates may have tried to hide these deficiencies at the expense of whoever they were advising. But, I never got any sense that the developers did.
I remember a post by someone on the mailing list that asked (and I'm paraphrasing here from memory, so I could be off): "Would you run your payroll system on PostgreSQL?" (implying that he bet his paycheck on postgresql) and a primary developer responded "not on 7.0, but on 7.1 [just released at the time], yes."
I really think that postgresql has moved a long way since that time. It's at 7.4.1 right now, and I I simply haven't heard reports for a long time about any sort of "weirdness". It's a 24/7 system now. Heck, I was running a 7.1.x system for a long time with no problems.
Now, I get the same feeling about hidden issues with MySQL from the advocates of that system. But I actually check up on my facts, and I've decided that I would prefer not to use a database that thinks Feb 31st is a date.
Granted, I understand that the features of PostgreSQL have to develop a track record of actually working. Well, all the things you mention were fixed at least a year ago, and yes, they do work.
I also understand that MySQL works for you. But what I don't understand is why PostgreSQL doesn't work for you. I'm not saying you should switch to postgresql, but I would like to hear of an actual problem someone had using it in the last 12 months (or heck, 24 months) that MySQL solved. What can PostgreSQL possibly do that would attract your attention again?
From my perspective, MySQL has nothing to attract me away from PostgreSQL. MySQL improvements have been suggested many times, and they're working on them. What improvements do you suggest for PostgreSQL?
-- Social scientists are inspired by theories; scientists are humbled by facts.
Slashdot Mirror
In the spirit of the interesting compatibility version numbering post, informative version numbering is straightforward. Every version of software should be go through alpha, beta and release versions, for each change. When starting to edit the source code, increment the version number first. The number to increment, whether .., is determined by kind of compatibility the change will discard from the previous version: major=GUI/features, minor = data formats / APIs, build/patch = bugfixes. Once the number is first incremented, it is an ALPHA version, for testing/revision within the group (even of one person) that has developed it (any designers or programmers). Once alpha testing is complete within the developer group, whose preconceptions influence their testing, it is a BETA version, for testing outside of the developer group (customers, end users, random taste tests). Once beta testing/revision is complete, when all revision is complete, it is a RELEASE version, for another round of idiot-check retesting, usually by the release team testing with the packaging and distribution tools, with marketdroids given a more serious voice, when they take responsibility for unleashing it on the market. When alpha, beta or release phase revisions change compatibility with the previous version's GUI/features or data formats / APIs, the major or minor version number, respectively, is incremented, and it goes back to alpha testing. So an app might have version numbering like:
2.3 (released) -> 2.3.1a -> 2.3.1b -> 2.3.1 (released) -> 2.4a -> 2.4.b -> 2.4.1a -> 2.4.2a -> 2.4.3a -> 2.4.3b -> 2.4.4a -> 2.4.5a -> 2.4.5b -> 2.4.5 (released)
The versions released would be known only as 2.3, 2.3.1, and 2.4.5. 2.3 would be binary compatible with 2.3.1, and the same GUI and features, but 2.4.5 would only look and feel like 2.3, without binary compatibility (either data formats or APIs). This scheme makes version numbers actually useful, to consumers, new developers, and even automated interoperability systems (a la apt-get). It also offers an incentive to keep version numbers lower, as higher numbers reflect more changes (get it right the first time). At least in the minor and build/patch numbers. Most importantly, it reflects a reasonable test/revise/release discipline. So the numbers are the tail, wagged by the dog.
--
make install -not war
I have been looking for a long time for a MySQL person to actually say something that bugged them about PostgreSQL, and why they couldn't use it.
When I started using postgresql, at 6.5.3, it was deficient in many ways. Advocates may have tried to hide these deficiencies at the expense of whoever they were advising. But, I never got any sense that the developers did.
I remember a post by someone on the mailing list that asked (and I'm paraphrasing here from memory, so I could be off): "Would you run your payroll system on PostgreSQL?" (implying that he bet his paycheck on postgresql) and a primary developer responded "not on 7.0, but on 7.1 [just released at the time], yes."
I really think that postgresql has moved a long way since that time. It's at 7.4.1 right now, and I I simply haven't heard reports for a long time about any sort of "weirdness". It's a 24/7 system now. Heck, I was running a 7.1.x system for a long time with no problems.
Now, I get the same feeling about hidden issues with MySQL from the advocates of that system. But I actually check up on my facts, and I've decided that I would prefer not to use a database that thinks Feb 31st is a date.
Granted, I understand that the features of PostgreSQL have to develop a track record of actually working. Well, all the things you mention were fixed at least a year ago, and yes, they do work.
I also understand that MySQL works for you. But what I don't understand is why PostgreSQL doesn't work for you. I'm not saying you should switch to postgresql, but I would like to hear of an actual problem someone had using it in the last 12 months (or heck, 24 months) that MySQL solved. What can PostgreSQL possibly do that would attract your attention again?
From my perspective, MySQL has nothing to attract me away from PostgreSQL. MySQL improvements have been suggested many times, and they're working on them. What improvements do you suggest for PostgreSQL?
Social scientists are inspired by theories; scientists are humbled by facts.