(mysql.info) choosing-version

(mysql.info) choosing-distribution-format
 
 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  news. 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
       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  mysql-benchmarks.
 
    * The `crash-me' test
 
      This test tries to determine what features the database supports
      and what its capabilities and limitations are.  See 
      mysql-benchmarks.
 
 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.
Info Catalog
(mysql.info) which-version
(mysql.info) choosing-distribution-format
automatically generated byinfo2html