What happened to MySQL release 5.0.22? Be careful when you update!
MySQL officially announced release 5.0.22 today (the release notes in the manual were not yet updated to reflect this at the time of writing, they might be when you read this). It's a security fix release only, based on the previous 5.0.21 release. So be careful if you're currently running a preview release of what was tagged 5.0.22 before, this has now become 5.0.23. So you will lose some of the functionality or bug fixes by switching from a 5.0.22 preview to the final 5.0.22 release (it's not an update but sort of a crossdate).
The right way of handling the situation therefore is:
- If you're currently running 5.0.21: Update to 5.0.22 to get the security fix for the SQL-injection hole in the multibyte encoding processing.
- If you're currently running a 5.0.22 preview (either supplied by MySQL Network or built from a source snapshot):
- Stay on your 5.0.22 preview and wait for the 5.0.23 release if you're not affected by the SQL-injection hole.
- Apply the workaround mentioned in the 5.0.22 release announcement or build a 5.0.23 preview including the security patch if you might be affected by the security hole.
- Update to the 5.0.22 release only if you don't need any of the bug fixes or new features in your previous 5.0.22 preview but might be affected by the security hole.
I just updated my post on VIEW bugs to reflect the new version numbering.
I know there was some discussion on release tagging before, when a similar thing happened and a release was tagged 5.0.20a in violation of MySQL's version numbering policy. But I think this policy should actually be changed, as a version numbering such as 5.0.21a or 5.0.21-p1 (patch level 1) would help to avoid such a confusion arising from a security fix release that suddenly replaces a previously planned release and makes it necessary to retag all changes to a later version.
