[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
We don't believe in a complete freeze, as this also leaves out bug fixes and things that "must be done." "Somewhat frozen" means that we may add small things that "almost surely will not affect anything that's already working." Naturally, relevant bugfixes from an earlier series propagate to later series.
The MySQL naming scheme uses release names that consist of three
numbers and a suffix, for example, mysql-4.1.0-alpha
.
The numbers within the release name are is interpreted like this:
4
) is the major version and also describes the
file format. All Version 4 releases have the same file format.
1
) is the release level.
Taken together, the major version and release level constitute the release
series number.
0
) 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 some large section of
new code that hasn't been 100% tested. Known bugs (usually there are none)
should be documented in the News section. See section C. MySQL Change History. There are also new
commands and extensions in most alpha releases. Active development that
may involve major code changes can occur in an alpha release, but everything
will be tested before issuing a release. For this reason, there should be
no known bugs in any MySQL release.
beta
means that all new code has been tested. No major new
features that could cause corruption in old code are added. There should
be no known bugs. A version changes from alpha to beta when there
haven't been any reported fatal bugs within an alpha version for at least
a month and we have no plans to add any features that could make any old
command unreliable.
gamma
is a beta that has been around a while and seems to work fine.
Only minor fixes are added. This is what many other companies call a release.
MySQL uses a naming scheme that is slightly different from most other products. In general, it's relatively safe to use any version that has been out for a couple of weeks without being replaced with a new version within the 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.
Note that all releases have been tested at least with:
crash-me
test
Another test is that we use the newest MySQL version in our internal production environment, on at least one machine. We have more than 100 gigabytes of data to work with.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |