The points below summarizes the situation as of September 2009:

1) We support any MySQL version (whether official MySQL builds or 'fork' builds) that a recent standard MySQL client library can communicate with. That is from 3.23 to 6.x.

2) However any report of issues with a 3.23 version that is not 3.23.58 and any 4.0 version that is not 4.0.26 or 4.0.27 will trigger the standard reply "We don't care" if the issue can be resolved by upgrading to 3.23.58 or 4.0.26+.

3) for 4.1, 5.0 and 5.1 versions we also "do not care" about issues with alpha/beta/RC versions if issue can be resolved by upgrading to a stable/GA version in the same tree.

4) for 4.1 specifically we recommend 4.1.20 or higher. Some Linux distributions (most important RHEL4) originally shipped with 4.1.10. This version has serious bugs in charset handling (of which most were fixed in 4.1.12). Official RHEL 4.1.20 builds are available for upgrade by RHEL4 users.

5) for 5.0 specifically we recommend 5.0.51a or higher.

6) for both 5.0 (ie: post 5.0.51a) and 5.1 stable/GA releases it also may happen that we will not resolve an issue if an upgrade to latest stable versions resolves the issue. It depends on the nature and seriousness of the issue and the effort required to fix or 'work around' the issue with the older version.

7) for versions that are only available as alphas/betas/RCs (currently 5.4 and 6.0) we will consider only the most recent version released at the time of reporting. There is no guarantee that we will resolve an issue with those if we do not consider the issue critical. We may decide to 'wait and see' as there are often significant change of functionality with each new release of those.

8) and finally versions only available from development trees (binaries from MySQL Labs, servers built from source from the source code development trees) we will generally not take action if no other build is affected and if it is not obvious that there is a bug that should be fixed under any circumstance.