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
MySQL Suitability for,,, stuff.
by
NeGz
·
· Score: 2, Insightful
I've just skimmed over the comments, and seen that a few people mention that MySQL is not yet ready for use on a critical server in the real world.
Now, I'm no database expert at all, and I've only ever used MySQL for databases. But as far as I know, slashdot itself runs on MySQL (supporting evidence?). Now, this is a site that gets a hojillion comments per article, several articles per day, with enough viewers to crush lesser sites at will. Surely this suggests that MySQL must be ready for "mission critical" use, at least in some circumstances.
Just an observation from a database newbie.:)
Re:Serious bug
by
neverkevin
·
· Score: 2, Insightful
Maybe you sould have made it clear in your post that it was "sarcastically funny, but honest criticism" instead of making it look like flamebait and tring to explain it is not after the fact. Bitching about how you got modded is lame.
MySQL hires people from around the world, and not everyone celebrates Christmas (though for the company it is a holiday). Several people showed up to our scrum meeting this morning and I have spent the last couple of hours talking about a few slight changes to our protocol this morning.
Personally I will later on be celebrating the day by watching Return of the King:)
-- You can't grep a dead tree.
Re:MySQL and PHP legalities
by
Anonymous Coward
·
· Score: 1, Insightful
The problem is that the licences don't allow you to distribute MySQL and a MySQL-enabled PHP together, hence for example Red Hat is still including MySQL 3.x with their newer offerings like Fedora.
There is however no problem with you downloading MySQL from mysql.com and PHP from php.net, configuring php to use your local MySQL copy and then running the two together. At least for Linux users this is no problem, since it's literally a 3 minute operation. It's on Windows it gets ugly when you have to recompile PHP, how many windows users have (or want) a compiler around?
Re:For all the PostgreSQL zealots out there...
by
ngunton
·
· Score: 2, Insightful
Thanks for nicely illustrating my point!
Nah, more likely it's the disgust that the more experienced developers feel with an obvious charletan that claims that well-proven techniques aren't necessary. Kinda like if ten years ago Yuga had insisted that air-bags, seat belts, and bumpers weren't needed "by most people in most situations". Yeah, right.
yep, I've occasionally developed trivial databases without [subqueries]. But I've seldom developed a serious database without them.
Wow, thanks! Another snide and elitist response! MySQL works very well for a very large number of people, thanks very much. Calling someone who challenges your viewpoint (that transactions MUST be used everywhere and if you don't do subqueries then you're somehow a charletan and not a "real" developer of "serious" databases) is just more of the same drivel I've been reading all this time...
You know, it's not the fact that either database has this or that feature that really grates on me here. It's the attitude of the people who make claims that you can only be developing "serious" databases if you require subqueries, or that "MySQL is a toy" and the classic "it's not a real database"... these are extreme and unnecessary statements that fly in the face of people's REAL WORLD experiences with this RELATIONAL DATABASE.
Sorry, but Yes, it IS a real database. And no, I truly don't appreciate the dismissive, elitist attitudes of people like you. You conveniently ignored the 8k row limits and the VACUUM blocking yet again, because it doesn't fit with your cozy world view. Oh well.
Nice try, but sorry, no dice. Don't you understand my main point, which is that by making your responses so repellent and insulting, you truly don't do yourself or anyone else in the PostgreSQL camp any favors. The zealots will just cheer (as usual) while the rest of us just sigh and discount any valid points you may have made because they are buried inside snide, intellectually elitist remarks.
Re:Windows-like version numbers
by
BrynM
·
· Score: 2, Insightful
The troll probably has installed MySQL under Win32 on a badly fragmented NTFS partition. I can attest first hand that it will kill performance for MySQL. NTFS performance degrades badly when highly fragmented, I don't care how good the drive hardware is. Kepp a good defrag too handy if you are running under Win32 and have files that grow.
-- US Democracy:The best person for the job (among These pre-selected choices...)
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
The Apache 2.0.x series has seemed similar. They weren't production ready until the 2.x.3?'s.
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've just skimmed over the comments, and seen that a few people mention that MySQL is not yet ready for use on a critical server in the real world.
:)
Now, I'm no database expert at all, and I've only ever used MySQL for databases. But as far as I know, slashdot itself runs on MySQL (supporting evidence?). Now, this is a site that gets a hojillion comments per article, several articles per day, with enough viewers to crush lesser sites at will. Surely this suggests that MySQL must be ready for "mission critical" use, at least in some circumstances.
Just an observation from a database newbie.
Maybe you sould have made it clear in your post that it was "sarcastically funny, but honest criticism" instead of making it look like flamebait and tring to explain it is not after the fact. Bitching about how you got modded is lame.
MySQL hires people from around the world, and not everyone celebrates Christmas (though for the company it is a holiday). Several people showed up to our scrum meeting this morning and I have spent the last couple of hours talking about a few slight changes to our protocol this morning.
:)
Personally I will later on be celebrating the day by watching Return of the King
You can't grep a dead tree.
The problem is that the licences don't allow you to distribute MySQL and a MySQL-enabled PHP together, hence for example Red Hat is still including MySQL 3.x with their newer offerings like Fedora.
There is however no problem with you downloading MySQL from mysql.com and PHP from php.net, configuring php to use your local MySQL copy and then running the two together. At least for Linux users this is no problem, since it's literally a 3 minute operation. It's on Windows it gets ugly when you have to recompile PHP, how many windows users have (or want) a compiler around?
Thanks for nicely illustrating my point!
Nah, more likely it's the disgust that the more experienced developers feel with an obvious charletan that claims that well-proven techniques aren't necessary. Kinda like if ten years ago Yuga had insisted that air-bags, seat belts, and bumpers weren't needed "by most people in most situations". Yeah, right.
yep, I've occasionally developed trivial databases without [subqueries]. But I've seldom developed a serious database without them.
Wow, thanks! Another snide and elitist response! MySQL works very well for a very large number of people, thanks very much. Calling someone who challenges your viewpoint (that transactions MUST be used everywhere and if you don't do subqueries then you're somehow a charletan and not a "real" developer of "serious" databases) is just more of the same drivel I've been reading all this time...
You know, it's not the fact that either database has this or that feature that really grates on me here. It's the attitude of the people who make claims that you can only be developing "serious" databases if you require subqueries, or that "MySQL is a toy" and the classic "it's not a real database"... these are extreme and unnecessary statements that fly in the face of people's REAL WORLD experiences with this RELATIONAL DATABASE.
Sorry, but Yes, it IS a real database. And no, I truly don't appreciate the dismissive, elitist attitudes of people like you. You conveniently ignored the 8k row limits and the VACUUM blocking yet again, because it doesn't fit with your cozy world view. Oh well.
Nice try, but sorry, no dice. Don't you understand my main point, which is that by making your responses so repellent and insulting, you truly don't do yourself or anyone else in the PostgreSQL camp any favors. The zealots will just cheer (as usual) while the rest of us just sigh and discount any valid points you may have made because they are buried inside snide, intellectually elitist remarks.
The troll probably has installed MySQL under Win32 on a badly fragmented NTFS partition. I can attest first hand that it will kill performance for MySQL. NTFS performance degrades badly when highly fragmented, I don't care how good the drive hardware is. Kepp a good defrag too handy if you are running under Win32 and have files that grow.
US Democracy:The best person for the job (among These pre-selected choices...)
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.