2.1.2.1. Choosing Which Version of MySQL to Install
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.1 is the next development release series and is
the series in which new features are to be implemented.
Alpha releases are available now to allow widespread
testing by interested users.
MySQL 5.0 is the current stable (production-quality)
release series. New releases are issued for bugfixes only;
no new features are being added that could effect
stability.
MySQL 4.1 is the previous stable (production-quality)
release series. New releases are issued for critical
bugfixes and security fixes. No significant new features
are to be added to this series.
MySQL 4.0 and 3.23 are the old stable (production-quality)
release series. These versions are now retired, so new
releases are issued only to fix extremely critical bugs
(primarily security issues).
We do not believe in a complete code freeze because this
prevents us from making bugfixes and other fixes that must be
done. By “somewhat frozen” we mean that 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.
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, we recommend going with the production
release series. Currently, this is MySQL 5.0. 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 non-seamless 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. Note that development releases are not as stable as
production releases.
If you want to use the very latest sources containing all
current patches and bugfixes, you can use one of our BitKeeper
repositories. These are not “releases” as such,
but are available as previews of the code on which future
releases are to be based.
The MySQL naming scheme uses release names that consist of
three numbers and a suffix; for example,
mysql-5.0.12-beta. The
numbers within the release name are interpreted as follows:
The first number (5) is
the major version and describes the file format. All MySQL
5 releases have the same file format.
The second number (0) is
the release level. Taken together, the major version and
release level constitute the release series number.
The third number (12) 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 contains new features that have not been
thoroughly tested. Known bugs should be documented in the
News section. See Appendix D, MySQL Change History. 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 means that the
release is intended to be feature-complete and that all
new code has been tested. No major new features that are
added. There should be no known critical bugs. A version
changes from alpha to beta when there have been no
reported fatal bugs within an alpha version for at least a
month and we have no plans to add any new features that
could make previously implemented features unreliable.
All APIs, externally visible structures, and columns for
SQL statements will not change during future beta, release
candidate, or production releases.
rc is a release
candidate; that is, a beta that has been around for a
while and seems to work well. Only minor fixes are added.
(A release candidate is what formerly was known as a gamma
release.)
If there is no suffix, it means that the version has been
run for a while at many different sites with no reports of
critical repeatable bugs other than platform-specific
bugs. Only critical bugfixes are applied to the release.
This is what we call a production (stable) or
“General Availability” (GA) release.
MySQL uses a naming scheme that is slightly different from
most other products. In general, it is usually safe to use any
version that has been out for a couple of weeks without being
replaced by a new version within the same release series.
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
The mysql-test directory contains an
extensive set of test cases. We run these tests for
virtually every server binary. See
Section 27.1.2, “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.4, “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.4, “The MySQL Benchmark Suite”.
We also test the newest MySQL version in our internal
production environment, on at least one machine. We have more
than 100GB of data to work with.
