By Carsten | March 26, 2008
Aside from Ronald’s totally correct observations re. the MySQL release schedule in general, “late Q2″ leads lots of current 5.0 users to a rather “interesting” situation, dictated by a questionable decision on the part of the MySQL marketing team several years back: If “late Q2″ sticks , then you’ve got just over 6 months to do the switchover to 5.1 before 5.0 goes EOL.
Back in 2006, it was decided by the MySQL marketing department that from now on, major versions of MySQL should have a lifetime of 2 years from their GA release date until they were declared EOL to non-network subscribers. This caused a lot of protests from almost everyone on the engineering team and most everyone else with a reasonable insight into MySQLs ability to make GA releases.
(At this point, I should perhaps point out to those that don’t know me, that I worked for MySQL from 2002 until late 2007.)
After overruling those protests, said marketing people published what is now known as the MySQL Lifecycle Policy. At that time, it had a lot of other problems (such as using Capitalized Words for things like “Major Release” and “Severity Level” without ever defining what was actually meant by those terms). Happily, most of those other issues have been addressed over time, but that stupidly optimistic 2-year time frame still remains.
So what does that mean for MySQL 5.0? Well, according to said policy, 5.0 was released on Oct. 24, 2005 and that active support for that product ends on Dec. 31st 2008. If you happen to hit a bug in 5.0 that seriously disrupts your setup, you’d just better hope you have time to implement a workaround. If it’s something that brings your systems to a total halt, MySQL will decide whether they think it’s worth their time to deal with it. If you have bought an “extended lifetime” insurance.
Presuming that the “late Q2″ date holds, this means that you’ve got slightly more than 6 months to do your testing and re-deploy all your existing applications.
Such is the price for letting the marketing department make long-term decisions without regard to the real world around them.
And now we all get to pay the price for that decision. Personally, I’m in the happy situation that I was able to convince my employer to run a new version of one of two major systems on 5.1-Beta several months ago. We will have the chance to do so over the next several months for the other as well, which is receiving a major overhaul anyway. But that is pure coincidence, and the timetables might as well have been removed by a year from those dates. I’m happy that I’m not in the shoes of major MySQL users out there who happen to be in a much more constrained situation.
I’m also happy that I’m not one of those people in the MySQL support team who will undoubtedly have to deal with a lot of unhappy customers over the next several months. Those guys are fantastic, but this is going to take a toll on them.
It’s completely reasonable that MySQL sets an EOL date for a major version when a new one comes out. You can’t expect a software company to keep upgrading old versions forever. But that EOL date should be set when you have a firm release date for the next version, not three years ahead of time when you don’t have a clue as to when the next version is actually going to be available.
Don’t get me wrong: I have the deepest respect for many members of the MySQL marketing team. They have had a key part in moving MySQL to where it is today as a viable alternative to the Big Iron databases in the enterprises. Even more importantly, many of the same people have done an absolutely amazing job within MySQL, working as customer advocates toward the engineers and others who might sometimes have problems understanding what the world is like outside their own narrow scope. They deserve a lot of kudos for that.
But the decision to implement a 2-year EOL date based on the release date of the product was as stupid then as it is now. We can only hope that other software companies, startup or otherwise, will learn from this.
Topics: MySQL |