(mysql.info.gz) Choosing version

(mysql.info.gz) 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.0 is the newest development release series and is under
      very active development for new features. Alpha releases have been
      issued to allow more widespread testing.
 
    * MySQL 4.1 is the current stable (production-quality) release
      series.  New releases are issued for bugfixes. No new features are
      added that could diminish the code stability.
 
    * MySQL 4.0 is the previous stable (production-quality) release
      series.  New releases are issued for bugfixes. No new features are
      added that could diminish the code stability.
 
    * MySQL 3.23 is the old stable (production-quality) release series.
      This series is retired, so new releases are issued only to fix
      critical bugs.
 
 
 We don't believe in a complete freeze, as this also leaves out bugfixes
 and things that "must be done."  "Somewhat frozen" means that we may add
 small things that "almost surely will not affect anything that's
 currently working." 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 4.1.  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 old system and want to upgrade, but don't 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 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 will be based.
 
 The MySQL naming scheme 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 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.   News.
      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.
 
    * If there is no suffix, it means that the version has been run for a
      while at many different sites with no reports of 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'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.
 
 All releases have been tested at least with:
 
 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
      see whether the latest batch of optimizations actually made the
      code faster.   MySQL Benchmarks.
 
 The `crash-me' test
      This test tries to determine what features the database supports
      and what its capabilities and limitations are.   MySQL
      Benchmarks.
 
 Another test is that we use 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.gz) Which version
(mysql.info.gz) Choosing distribution format
automatically generated byinfo2html