In his MySQL Conference Roundup post, Russell confessed his confusion about how MySQL versions are numbered and developed:
I was actually disappointed to hear that 4.1 won't be going beta until next month and won't be in production until Q4!!! I was told it was going to be production *a lot* sooner (as in this week). Urgh. As I'm using the spatial indexing stuff, and it'd be nice if it was more solid. And what about 5.0? I thought 4.1 was going to become 5.0 when launched? I'm confused.
Heh. It is confusing, especially since different projects do it differently (Linux kernel, Apache, etc). The good news is that MySQL is fairly easy to understand.
There are always at least three versions (or categories of versions) to know about. Let's give them names and rough descriptions that match the way I think about it.
- legacy: these versions are no longer actively developed. If you find a bug, you're usually told to upgrade to stable. Major security flaws, however, generally seem to be fixed. Today this is the 3.23.xx series.
- stable: the stable series is safe for use in production. Bugs are actively fixed and new versions appear a few times per year. Today this is the 4.0.xx series.
- development: this is where all the new stuff happens. The code may or may not be safe for production use at any given time and may or may not exist as alpha or beta releases as they reach major milestones and need testing. Today this is both 4.1.xx and 5.0.xx
That last bit is where the confusion comes from. The 4.1.xx series is likely to go beta in a month or two (I'd guess). It's where you're going to find spatial (2-D) indexing, subqueries, multiple character set support, prepared statements, and lots of other goodies. The 5.0.xx series is going to take longer--just as you'd expect. It's where the work for stored procedures is going on.
So 4.1 will not become 5.0 when launched, but 5.0 will certainly inherit all of 4.1's features.
It's also worth checking the relevant section of the MySQL manual to get their take on all this.
Oh, he also heavily pimps High Performance MySQL in that post too. Thanks, Russ!
Posted by jzawodn at April 21, 2004 08:29 PM
My personnal gripe is not the confusing numbering, it's the speed at which new features are added. Given that triggers should show up in 5.1, it will be several years before we can start to use them in a production environement.
And I don't even know why they choosed to implement stored procedures without triggers.
My stance has always been that if you have a dire need for stored procedures and triggers and all that jazz, then why are you using MySQL?
Granted, they would be nice to have, but I'm not "waiting" on them by any means. I think that the development teams are under the impression that most of their users aren't in dire need of these features.
My stance has always been that if you have a dire need for stored procedures and triggers and all that jazz, then why are you using MySQL?
Because I have 100k+ lines of application code with lots of MySQL queries that I don't have the time to port to something better. Unfortunately when I started writing it in 1999 MySQL was pretty much the only game in town, PostgreSQL wasn't really an option back then.
It's not that bad, but I could really use stored procedures and triggers if they were available.
I'm in the same boat as you. I started writing web applications back in 98/99. Most of my hundreds of thousands of lines of code since then call mysql client functions directly. It wasn't until this last year that I started writing all of my new stuff with an abstraction class. But that still doesn't change the fact that the sql queries need to be fixed if I change database servers.
However, if I knew that I wanted to use stored procedures, triggers, subqueries, and views, then I'd probably be rewriting most of the database access for my application anyway. I mean, thats the whole point of stored procedures, right? You do more work on the database side and less work in your application. So you will be changing your application's database code anyway.
My projects are fairly small (actually quite large for web apps, but small compared to non-web apps) so it would be easy for me to make this change on a future project if I decided that stored procedures were going to be worth it. But then I'd have most of my apps running mysql and one running something else (postgres?) and that adds a lot of administrative work for me. So that is another thing to consider. All in all, I think we would all be a lot happier with these features in MySQL, but I'm not peeved that development is slow, because I *do* have the choice to switch or start using postgres on the side if I really thought the features were necessary. Somehow I have managed to get by without these features for the past 5 years. What is another year?
I've used stored procedures, triggers, and views with other databases before. And when I first started using MySQL I was like, why don't they have this? Now, I've found so many ways around them that are so much faster, that I don't really care if I ever have them. When they are finally available, I'm sure I can find some use for them, so I will use them. But they are not going to hold anything up.
Donny
Jeremy,
Can you explain something about the MySQL code itself, somebody explained this to me once and when I was at the MySQL conference somebody else told me a different story. So this seems like a good place to ask.
I was originally told by a MySQL employee, that the 3.23.x, 4.0.x, 4.1.x, and 5.0.x core code is all the same. The only difference is that you have add-ons, like subqueries in 4.1, or or multi-table updates in 4.0.x. So let's say they start working on 5.0 for the first time, they take the MySQL core code, take all of the add-ons in 3.23.x, all of the add-ons in 4.0.x, 4.1.x and that could basically be called the base of 5.0 before any 5.0.x extensions are added in.
Do you know if this is really how it's done? Or do they have a completely new CVS tree for each one with a completely seperate code base?
Thanks.
Donny
