We’ve discussed today how we should implement MySQL Version advisory in mk-audit tool. One obvious questions was to look at the end of life – it is often bad idea to run MySQL versions past end of life as even security bugs may not be fixed in these (though do not get paranoid, if you’re running MySQL in isolated environment the risk may be low).
So how does EOL schedule looks ?
MySQL defines Active Lifecycle and Extended Lifecycle for release where first one is 2 years since initial GA release and second is further 3 years of life in “critical bug fixes only” mode with releases available for premium (Silver+) Support offerings.
For MySQL Community users this means only releases within Active Life Cycle will be made. For example MySQL 4.1 had end of its Active Lifecycle in the end of 2006. and indeed Latest MySQL 4.1 available for the public is 4.1.22 while as Manual Says there were number of further releases with last one in March 2008 containing fixes for security and critical bugs.
It is also worth to note even though MySQL 5.0 successor (MySQL 5.1) is still not released as GA, MySQL 5.0 Active LifeCycle will end in end of 2008, unless there are changes means. If same policies as of MySQL 4.1 are followed we’ll soon see stop in MySQL community releases of MySQL 5.0 most likely before MySQL 5.1 will proven MySQL 5.0 replacement.
There is no blame on MySQL – it is no fun to support these old versions both for Support team (remembering these all old versions limitations) and for development team, and it costs, so somebody has to pay for this and this is exactly what premium MySQL Support levels are for.
My main point is – make sure you understand MySQL Release Policy and so what to expect whenever you’re MySQL customer or community user.
Shameless Plug: I guess hundreds of Percona customers are reading this blog so I should say how Percona treats old versions. We obviously recommend to upgrade when it makes sense while at the same time we have no restrictions in terms of supported versions. If customer chooses to run older version he may have more problems and these may take more time to deal with, so the bill would be higher. We are also happy to provide builds based on updated trees and backport fixes from the newer releases if MySQL has chosen not to backport bug because of its severity. We believe in freedom of choice.
I just spoke to Jeremy Cole – the ultimate source of freely available MySQL Enterprise Sources and Binaries and he kindly added recent MySQL 4.1 versions to the list:
http://mirror.provenscaling.com/mysql/community/binaries/4.1/
5.1 is so close to GA but just not yet.
It’s already three weeks since Zack Urlocker said it’s going to be a couple of more weeks 😉
http://www.eweek.com/c/a/Database/MySQL-51-Open-Source-Database-GA-Date-Approaching/
yingkuan,
MySQL 5.1 is “close” to GA but the date was moved few times and really GA is just the marketing tag – it is the main question what you would call GA. As I know so far 5.1 contains number of repeatable crash bugs which should not allow it to be called GA under older release guidelines but it is a choice if you want to follow them.
In my experience it takes at least 6 months for “GA” release for people to move – because of waiting, quality assurance etc.
Last time I checked, 5.1 also contained a number of optimizer bugs that make its performance degrade on queries that run well on 5.0.
Thanks Peter and Baron, but seriously how much sleep you guys have every day? You replied 12:59am and Baron 5:45am.
Don’t work too hard for you customers 😀
yingkuan,
We’re in different timezones. I’m in PST Baron is in EST. We have guys in Europe as well. So there is almost all the time somebody working. Though we often have long work days too 🙂