Comments on: What would make me buy MySQL Enterprise? http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/ Stay curious! Fri, 05 Sep 2008 06:42:08 +0000 http://wordpress.org/?v=2.2.2 By: Xaprb http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-14186 Xaprb Tue, 22 Jan 2008 21:42:21 +0000 http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-14186 James, thanks for the correction. James, thanks for the correction.

]]> By: James Day http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-14185 James Day Tue, 22 Jan 2008 21:27:44 +0000 http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-14185 You're not quite right about the way the Enterprise builds work at the moment. Here's the system: x.y.d: monthly rapid update, the latest bug fixes x.y.e: another MRU x.y.f: third MRU x.y.d.QSP: quarterly service pack version of x.y.d with fixes for newly found bugs introduced in b,c,d versions and critical new bug fixes, typically fewer than ten changes total. It's trying to address two competing goals: 1. People who want the most rapid bug fixes possible. Lots of people place a high positive value on this even though you and other stability first places put a large negative value on it. 2. People who want the most stable release possible. It does 1 fairly decently. It doesn't do 2 as well as you'd like but the time between base release and QSP does give some time to catch regression bugs. The Community release timings can help with this. A release around the time of the version that's intended to be the next QSP base version will give two months of Community use to find regression bugs. So today the message is, use the QSPs unless you need a bug fix that's not in an QSP, in which case use the MRU with the fix. QSPs might not be quarterly if we don't think the release is as good as we'd like. A faster major version release schedule is required to really cut out the behavior changes, so people can stand waiting for a bug fix that'll arrive only in a new major version. And more maturity of the newer features so there are less gotchas that need behavior changes. MySQL still needs to work on stability and consistency of features across versions - even just one decade of stable no changes required application compatibility is way beyond what MySQL delivers today unless you just don't upgrade the MySQL version that the application is using. Much more feature maturity will be needed before this sort of timescale is realistic but MySQL is trying to follow the relevant standards to increase the chance of getting things right the first time. New features from Community are a challenge of a different sort: how can a Community version user change to Enterprise if Enterprise doesn't have the features they have been using? The model is being tweaked to try to deal with this problem. Tweaking will probably continue. In deliberately picking versions that have been out for a while you're following exactly the practice that I adopted. You’re not quite right about the way the Enterprise builds work at the moment. Here’s the system:

x.y.d: monthly rapid update, the latest bug fixes
x.y.e: another MRU
x.y.f: third MRU
x.y.d.QSP: quarterly service pack version of x.y.d with fixes for newly found bugs introduced in b,c,d versions and critical new bug fixes, typically fewer than ten changes total.

It’s trying to address two competing goals:

1. People who want the most rapid bug fixes possible. Lots of people place a high positive value on this even though you and other stability first places put a large negative value on it.
2. People who want the most stable release possible.

It does 1 fairly decently. It doesn’t do 2 as well as you’d like but the time between base release and QSP does give some time to catch regression bugs.

The Community release timings can help with this. A release around the time of the version that’s intended to be the next QSP base version will give two months of Community use to find regression bugs.

So today the message is, use the QSPs unless you need a bug fix that’s not in an QSP, in which case use the MRU with the fix. QSPs might not be quarterly if we don’t think the release is as good as we’d like.

A faster major version release schedule is required to really cut out the behavior changes, so people can stand waiting for a bug fix that’ll arrive only in a new major version. And more maturity of the newer features so there are less gotchas that need behavior changes.

MySQL still needs to work on stability and consistency of features across versions - even just one decade of stable no changes required application compatibility is way beyond what MySQL delivers today unless you just don’t upgrade the MySQL version that the application is using. Much more feature maturity will be needed before this sort of timescale is realistic but MySQL is trying to follow the relevant standards to increase the chance of getting things right the first time.

New features from Community are a challenge of a different sort: how can a Community version user change to Enterprise if Enterprise doesn’t have the features they have been using? The model is being tweaked to try to deal with this problem. Tweaking will probably continue.

In deliberately picking versions that have been out for a while you’re following exactly the practice that I adopted.

]]> By: p http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-14152 p Sun, 13 Jan 2008 12:54:54 +0000 http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-14152 Well, bug above was found to be "Not a Bug", take it easy man. PostgreSQL and Firebird are better, but the MySQL guys are not that bad ;) Well, bug above was found to be “Not a Bug”, take it easy man.
PostgreSQL and Firebird are better, but the MySQL guys are not that bad ;)

]]> By: Dathan Pattishall http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13467 Dathan Pattishall Fri, 05 Oct 2007 19:58:30 +0000 http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13467 Yet another S1 Bug due to changes made to the bison layer of mysql. http://bugs.mysql.com/bug.php?id=31427 Obvious bugs are making there way into production, if this simple procedure was adopted by mysql I'm sure the bug would not see the light of day. Yet another S1 Bug due to changes made to the bison layer of mysql.

http://bugs.mysql.com/bug.php?id=31427

Obvious bugs are making there way into production, if this simple procedure was adopted by mysql I’m sure the bug would not see the light of day.

]]> By: Dathan Pattishall http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13466 Dathan Pattishall Fri, 05 Oct 2007 17:36:27 +0000 http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13466 I agree 100% to this post. I agree 100% to this post.

]]> By: Xaprb http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13307 Xaprb Tue, 14 Aug 2007 17:50:57 +0000 http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13307 Robert, between MySQL and PostreSQL, I always feel like I'm choosing between tiramisu and flan: I love them both. My employer uses MySQL. If that weren't true, I'm sure I'd be writing most of my articles about something else! Robert, between MySQL and PostreSQL, I always feel like I’m choosing between tiramisu and flan: I love them both. My employer uses MySQL. If that weren’t true, I’m sure I’d be writing most of my articles about something else!

]]> By: Xaprb http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13306 Xaprb Tue, 14 Aug 2007 17:47:40 +0000 http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13306 Konstantin, thanks for your thoughts. You made me realize it would be better if some of my sentences were phrased as "here's one way I think would be good," rather than "here's how that would have to change." I don't mean to insist on a specific outcome. I'm sure there are many possibilities I would consider a great value for Enterprise customers. Konstantin, thanks for your thoughts. You made me realize it would be better if some of my sentences were phrased as “here’s one way I think would be good,” rather than “here’s how that would have to change.” I don’t mean to insist on a specific outcome. I’m sure there are many possibilities I would consider a great value for Enterprise customers.

]]> By: Robert Treat http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13305 Robert Treat Tue, 14 Aug 2007 16:24:01 +0000 http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13305 I always find reading this types of posts re-assuring wrt my database of choice, which does follow a stable release processes, with bugfix only upgrade cycles, and no special gimmicks. OTOH it also bothers me to see smart people who give back very much to the community be put through the wringer when they should have to be. Hopefully things will work out one way or the other. I always find reading this types of posts re-assuring wrt my database of choice, which does follow a stable release processes, with bugfix only upgrade cycles, and no special gimmicks. OTOH it also bothers me to see smart people who give back very much to the community be put through the wringer when they should have to be. Hopefully things will work out one way or the other.

]]> By: Konstantin Osipov http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13303 Konstantin Osipov Mon, 13 Aug 2007 22:20:05 +0000 http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13303 You should take into account that 5.0 is not a release that we can be particularly proud of. You've rightfully noted that many 5.0 features are not ready for prime-time, and that many current bugfixes do not belong to a minor increment of a major server release. But in my opinion you're wrongly identifying the place that needs change - it is not the way we release to the enterprise, it is the way we release major versions. In future we should not release a version with half-baked features and call it enterprise-ready. In future we should not include a major changes into a production tree. But in order to get there, we need to change the way we deliver new features - this is in the works - and not necessarily the way we release to the enterprise. The idea, as far as I get it, is to give paying customers more options than non-paying customers. If an option is of little value to a paying customer, it is of course useless to sell it to him - but that's a different story. You should take into account that 5.0 is not a release that we can be particularly proud of.
You’ve rightfully noted that many 5.0 features are not ready for prime-time, and that many current bugfixes do not belong to a minor increment of a major server release.
But in my opinion you’re wrongly identifying the place that needs change - it is not the way we release to the enterprise, it is the way we release major versions.
In future we should not release a version with half-baked features and call it enterprise-ready.
In future we should not include a major changes into a production tree. But in order to get there, we need to change the way we deliver new features - this is in the works - and not necessarily the way we release to the enterprise. The idea, as far as I get it, is to give paying customers more options than non-paying customers. If an option is of little value to a paying customer, it is of course useless to sell it to him - but that’s a different story.

]]> By: Xaprb http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13302 Xaprb Mon, 13 Aug 2007 15:06:15 +0000 http://www.xaprb.com/blog/2007/08/12/what-would-make-me-buy-mysql-enterprise/#comment-13302 Thanks for the clarification; I should have read the feature list more carefully. I knew you could get custom builds, but I didn't know it was available for Basic too. Thanks for the clarification; I should have read the feature list more carefully. I knew you could get custom builds, but I didn’t know it was available for Basic too.

]]>