Choosing the Right MySQL Version and Reporting Bugs

By Arjen Lentz

People often ask me about which MySQL version they should use, whether they should consider upgrading, what to do when they find a bug, and so on. Though these things are covered in the MySQL Reference Manual and other places, this article aims to cover all the essentials in the one place.

What Versions Exist?

Updated August 29th 2005

Before we can choose, it is good to look first at what is actually available. Multiple versions of MySQL are available at the same time, which may initially be a bit confusing. Right now we have:

• MySQL 4.0 - Old production release
• MySQL 4.1 - GA/Production
• MySQL 5.0 - Beta

You will also notice an extra number in releases you can download, such as "4.1.10". The "10" is like the build number within the series. If you talk with someone about what version you use, it is vital to name this full version, i.e. "I am using version 4.1.10" so that people know exactly which version you are talking about. As you can imagine now, saying "I'm using the latest version" won't clarify anything at all!

As a hint, you can always find out which version of the MySQL server you are using by issuing the following SQL statement: SELECT VERSION(). This makes the MySQL server return a result set of one row with one column, containing a string with the exact version. Never rely on the version of your client software, as the server could be a completely different version.

There are actually more development phases than listed above, here is an overview:

• Alpha means that active development is taking place: new features are being added. Different new developments can actually interact and also have consequences for later versions, so adding new functionality is quite tricky. Good practises of software engineering are followed, so a design phase precedes the writing and integration of code into the rest of the server. Sometimes however, things may still change during the alpha stage - no matter how good the design, nothing beats real world experience and feedback.
• Beta means "feature freeze". All new features planned for this series have been implemented, and no fundamental changes will be made. This is a stabilizing phase in the development process, when the primary focus moves from implementation to bug fixing. The bug fixing process speeds up, since no new code is being added.
• Gamma can be regarded as a "release candidate". Of course, MySQL versions are available from the very first alpha, so this is not about a "release" in the sense that closed source companies use it. We use it in the sense of a aiming towards a "production quality" version. After the bug fixing in the beta stage, moving into the gamma phase is an indication of how we feel about things progressing: it's nearly ready to receive the production label, but we just want to make sure nothing funny shows up.
• Production is the next step, and it means we regard this series as generally suitable for production environments. We also call this "GA" (Generally Available) as that is the term often used in the policies of enterprise companies. Of course, even production versions can still contain bugs, there is no such thing as bug free software. In the production phase, reported bugs are fixed, but only if this does not change the overall behaviour of the server, as that might adversely affect other applications! In some situations a potential change would result in too much code being modified, putting the stability of the overall code at risk. In such cases the issue is documented and potentially fixed in the next series. People running a certain production series of MySQL must be able to safely update to a new release (for instance, 4.1.10 to 4.1.11) without having to worry about other things changing.
• Old is simply the previous production version, it means there is newer production version available. Some minor bugs may still be fixed, primarily security issues, but it must absolutely not affect any other behaviour so that people can rely on their stable production environment remaining stable if they upgrade within this series.

So how does a series come into existence? The first 5.0 was created as a branch from the 4.1 source code, and now they exist in parallel with different developers working on different aspects. These branches can diverge a bit (through changes in design) so it is not always possible to apply a patch for one series anywhere else. Before a release, branches are merged from the version below (where possible). As a rule, if a bug is fixed in the 4.1 series and the same issue exists in 5.0, then a fix will appear there also - by different means, if necessary.

To be absolutely clear, each series (eg., 4.1, 5.0) goes through its own release cycle. For example, 4.1.0 was alpha, 4.1.3 was beta, 4.1.4 was gamma, and 4.1.7 was the first production version. You can always find the complete log of changes here: http://dev.mysql.com/doc/mysql/en/news.html

Sometimes, a special release such as 4.1.10a comes out. This will either be because of a build problem on a specific platform (i.e. we made a mistake in the build process, and will do a new compile using the exact same source code snapshot) or because of a minor but important fix (such as a security issue) that needs to be put out before and separately from any new release.

Your Choice

If you are starting out with MySQL and only just getting to know everything, you generally want to go for the latest production series, or perhaps a gamma if it's available. The environment is known, and you are unlikely to encounter anything too odd. If you have a question, most people will be familiar with the version you are running.

If you need to choose for immediate deployment in a production environment, first check the base requirements of the applications you will be running. Good system administrators are conservative, so you probably want to choose the latest production series.

If you will be developing a new application, or are just curious about what's new, then go for the very latest available, even the most recent alpha. This allows you to utilize all the latest features in your application, benefit from new optimizations, and so on.

But what about any bugs, and when will this MySQL series be classified as production? Well, consider this. By the time your application is ready for production, chances are that the MySQL series you use has also reached maturity. It will also be included in new operating system releases by vendors.

But even if it has not reached production yet, you will come to know and trust this series - since all development and testing used it, you know exactly how it behaves for your particular application. So in this case, you can make your own assessment of "production ready".

Naturally, you can make a conservative choice here too, but that may mean that your application is not up to date with newer versions that customers have installed with their operating system, and also your application may not make optimal use of the features available. That can translate into a competitive disadvantage, so these are all things that need to be considered.

Any releases we make are required to pass our test suite. If a bug is found and fixed, a test case is added to the test suite, so that the bug cannot reoccur even if we "refactor" some of the code in a future version.

The production cycle is based on technical considerations, not marketing. Nevertheless we do appreciate that people and companies need to make choices based on our schedule. We operate by a roadmap and consciously limit the scope of a major release.

Source, Binary or RPM?

When you go to the download pages, you will probably have more than one choice of package to download. For many platforms, there are binaries available. If there are, I would definitely recommend you choose these, as they have been built by us in a controlled environment. We know the proper compiler version was used, with all the proper libraries.

Of course, if there are no binaries available for your platform, you will have to build from source. Always refer to the platform-specific information in the manual, and be sure you run the full test suite after building.

In addition to regular binaries, we build RPMs for Linux. If you use an RPM-based Linux distribution, this is by far the easiest. The RPM installation process automatically takes care of a number of steps that you would otherwise need to walk through manually. Many installation and upgrade problems stem from the simple skipping of steps from the instructions!

When to Upgrade

The fundamental rule applies: "if it ain't broke, don't fix it!" and many production environments still use MySQL 3.22 or even earlier. It just works. But that just applies to the old applications that were built for that version. Of course there are bugs that have long since been fixed, features optimized, and so on.

Generally, it is safe to update to a new release (build) within the same series, particularly if it is already labelled production. So if you run 4.1.10 and 4.1.11 is released, you will first want to check the changelog [http://dev.mysql.com/doc/mysql/en/news.html] to see if anything has changed which is relevant for you. If not, don't worry about it! But do keep an eye on things. If you have a MySQL Network subscription, you will automatically receive upgrade and security alerts for the specific version, platform and features you use http://www.mysql.com/network/.

When upgrading from one series to the next (such as 4.0 to 4.1), it is very important that you first read the upgrade information in the manual and follow all the instructions carefully.

It is generally not recommended to skip a series, i.e. go straight from a 4.0 to a 5.0, or from 3.23 to 4.1. If you must do this, read the upgrade information for each step very carefully, and perhaps do it in stages (first from 3.23 to 4.0, then from 4.0 to 4.1, with your own application tests in between).

Whenever you're upgrading, it is always a good idea to take extra backups. Provided the proper procedures are followed, upgrades will be safe for your data, but you can always make a mistake so it's good to not have to regret it.

Downgrades between series can be tricky and require additional care and possible manual work. Some help is available, for instance the mysqldump tool has a special option to create an SQL dump from MySQL 4.1 which is readable by a MySQL 4.0 installation. The MySQL manual also provides downgrading information http://dev.mysql.com/doc/mysql/en/downgrading.html. But still, it's better to avoid downgrading.

Bugs

As I already mentioned, there is no such thing as bug-free software. If you encounter a bug, I would say "that's great!" - please don't waste this excellent opportunity, and report it! Sure, someone else may encounter the same issue and do the report. But then again, perhaps they won't. So please take your own responsibility: by reporting bugs, you can assist your fellow users as well as support the overall development and software quality. Reporting bugs is an absolutely vital and integral part of the MySQL development process.

Let me digress for a moment, tying in this section with the previous. As you can see, the quality of any software is directly related to how many people use it (particularly early on in the development cycle!), and whether bugs are being reported and of course, fixed. MySQL has an excellent track record because of its very large user base - think of all the different environments and applications out there.

We may distill an interesting observation: the more people use a series from early on (such as an alpha or beta), the faster the desired production level quality will be reached. Contrary, if lots of people were to make a conservative choice with regard to what MySQL series they use (and pick an old one), this seriously affects the development cycle. Software maturity does not magically happen over time (like putting a good wine in a cellar), if it is not tested in the real world this directly hinders a series from maturing, simply because of insufficient feedback. So please please do make a progressive choice whenever possible!

Back to bugs... the MySQL bugs system is public, and can be found at http://bugs.mysql.com/. Here you can report a bug, but also search to see if perhaps someone else has already reported the same and what stage a fix is at. When reporting, please be very clear about the environment, and try to provide a reproducible case. Our developers are very good, but they are not clairvoyant: if they can't work out where the problem occurs, they cannot fix it. It is appreciated that providing reproducible cases is sometimes difficult, and sometimes a test case can be provided by someone else if you report it. But do try to be as clear and complete as possible with your initial report.

There is one important exception to the public nature of bugs, and that is when security is involved. Security reports go to a separate place [link to security feedback form], and are fixed before publication. When one of the security agencies finds a problem in MySQL (or any other program!) they do not keep it secret forever if the vendor is dragging their feet. But they always give the vendor a reasonable amount of time to put out a fix to their customers. So this too is good quality control.

Finally, a little note: sadly, we often find problems being reported in comments in the online manual, forum messages, mailing list messages.... what a waste! Why play hide and seek with developers about something so important as a bug? So please please always use the bugs system. The report can then be dealt with much faster, as it will be in the right place with all the necessary information.

Naturally, bug reporting is important not only for the MySQL server, but also to any of the utilities and the graphical tools.

MySQL Enterprise and Certified Binaries

The certified binaries operate on a more conservative release cycle than the latest and greatest "Community Edition" which you can download. Also, additional quality control steps are performed which enable certification. So for production environments, you may prefer to use only MySQL Network Certified Binaries. Partners can certify their applications for MySQL Enterprise and will then only support that particular known environment. See http://www.mysql.com/network/ for more information about MySQL Enterprise subscriptions.

Conclusion

I hope you have found this article of use, and always remember that you, the user, are a vital part of the MySQL ecosystem. It just wouldn't work without you. So from me and also on behalf of the MySQL developers, thank you very much for using MySQL, and for all the excellent bug reports and other feedback!