The first decision to make is whether you want to use a production (stable) release or a development release. In the MySQL development process, multiple release series co-exist, each at a different stage of maturity.
MySQL 5.6: Latest General Availability (Production) release
MySQL 5.5: Previous General Availability (Production) release
MySQL 5.1: Older General Availability (Production) release
MySQL 5.0: Older Production release nearing the end of the product lifecycle
MySQL 4.1, 4.0, and 3.23 are old releases that are no longer supported.
See http://www.mysql.com/about/legal/lifecycle/ for information about support policies and schedules.
Normally, if you are beginning to use MySQL for the first time or trying to port it to some system for which there is no binary distribution, use the most recent General Availability series listed in the preceding descriptions. All MySQL releases, even those from development series, are checked with the MySQL benchmarks and an extensive test suite before being issued.
If you are running an older system and want to upgrade, but do not want to take the chance of having a nonseamless upgrade, you should upgrade to the latest version in the same release series you are using (where only the last part of the version number is newer than yours). We have tried to fix only fatal bugs and make only small, relatively “safe” changes to that version.
If you want to use new features not present in the production release series, you can use a version from a development series. Be aware that development releases are not as stable as production releases.
We do not use a complete code freeze because this prevents us from making bugfixes and other fixes that must be done. We may add small things that should not affect anything that currently works in a production release. Naturally, relevant bugfixes from an earlier series propagate to later series.
If you want to use the very latest sources containing all current patches and bugfixes, you can use one of our source code repositories (see Section 2.9.2, “Installing MySQL from a Development Source Tree”). These are not “releases” as such, but are available as previews of the code on which future releases are to be based.
The naming scheme in MySQL 4.1 uses release names
that consist of three numbers and a suffix; for example,
mysql-4.1.2-alpha. The numbers within the
release name are interpreted like this:
The first number (
4) is the major
version and also describes the file format. All version 4
releases have the same file format.
The second number (
1) is the release
level. Taken together, the major version and release level
constitute the release series number.
The third number (
2) is the version
number within the release series. This is incremented for
each new release. Usually you want the latest version for
the series you have chosen.
For each minor update, the last number in the version string is incremented. When there are major new features or minor incompatibilities with previous versions, the second number in the version string is incremented. When the file format changes, the first number is increased.
Release names also include a suffix to indicates the stability level of the release. Releases within a series progress through a set of suffixes to indicate how the stability level improves. The possible suffixes are:
alpha indicates that the release is for preview purposes only. Known bugs should be documented in the News section (see Appendix C, MySQL Release Notes). Most alpha releases implement new commands and extensions. Active development that may involve major code changes can occur in an alpha release. However, we do conduct testing before issuing a release.
beta indicates that the release is appropriate for use with new development. Within beta releases, the features and compatibility should remain consistent. However, beta releases may contain numerous and major unaddressed bugs.
All APIs, externally visible structures, and columns for SQL statements will not change during future beta, release candidate, or production releases.
rc indicates a Release Candidate. Release candidates are believed to be stable, having passed all of MySQL's internal testing, and with all known fatal runtime bugs fixed. However, the release has not been in widespread use long enough to know for sure that all bugs have been identified. Only minor fixes are added. (A release candidate is what formerly was known as a gamma release.)
If there is no suffix, it indicates that the release is a General Availability (GA) or Production release. GA releases are stable, having successfully passed through all earlier release stages and are believed to be reliable, free of serious bugs, and suitable for use in production systems. Only critical bugfixes are applied to the release.
All releases of MySQL are run through our standard tests and benchmarks to ensure that they are relatively safe to use. Because the standard tests are extended over time to check for all previously found bugs, the test suite keeps getting better.
All releases have been tested at least with these tools:
An internal test suite.
mysql-test directory contains
an extensive set of test cases. We run these tests for
every server binary. See
Section 18.1.2, “The MySQL Test Suite”, for more information
about this test suite.
The MySQL benchmark suite. This suite runs a range of common queries. It is also a test to determine whether the latest batch of optimizations actually made the code faster. See Section 7.1.3, “The MySQL Benchmark Suite”.
The crash-me test. This test tries to determine what features the database supports and what its capabilities and limitations are. See Section 7.1.3, “The MySQL Benchmark Suite”.