La première décision à prendre est de savoir si vous voulez utiliser la dernière version de développement ou la dernière version stable :
MySQL 5.0 est la nouvelle version de développement, et les nouvelles fonctionnalités sont activement développées. Jusque récemment, elle n'était disponible qu'en avant-première, sous BitKeeper. Une version alpha a été publiée depuis, pour permettre la diffusion large de la version, à des fins de tests.
MySQL 4.1 est la version de développement, qui propose de nouvelles fonctionnalités majeures. Elle est toujours en version alpha. Les sources et le binaire sont disponibles pour tests et développement.
MySQL 4.0 est la version stable courante, pour la production. Les nouvelles versions publiées sont des corrections de bogues. Aucune nouvelle fonctionnalité ne sera ajoutée, pour ne pas diminuer la stabilité du code.
MySQL 3.23 est l'ancienne version de production. Cette série est retirée, et les nouvelles versions ne feront que corriger les bogues critiques.
Nous ne croyons pas au gel complet d'une version, et cela nous laisse de la place pour les corrections de bogues et les fonctionnalités qui ``doivent être faites.'' ``Un peu gelé'' signifie que nous pourrions ajouter de petites touches, qui ``n'affecterons pas ce qui fonctionne déjà, presque sûrement.'' Naturellement, les corrections de bogues des séries précédentes se propage aux nouvelles versions.
En règle générale, si vous utilisez MySQL pour la première fois ou si vous essayer de le porter vers un système pour lequel il n'existe pas de distribution binaire, nous vous recommandons d'utiliser la dernière version stable (actuellement la version 4.0). Notez que toutes les versions de MySQL sont passées aux bancs de tests MySQL avant chaque sortie (même les versions de développement).
D'autre part, si vous utilisez un vieux système et que vous voulez procéder à une mise à jour, sans pour autant risquer de mettre à jour sans raison, vous devriez mettre à jour vers la dernière version de la même branche que celle que vous êtes en train d'utiliser (dans le cas où un numéro de version supérieur existe). Nous avons essayé de résoudre uniquement les bogues fatals et de produire des correctifs petits et sûrs pour cette version.
Si vous voulez utiliser de nouvelles versions qui ne sont pas présentes dans la version de production, vous pouvez utiliser la version de développement. Notez que les versions de développement ne sont pas aussi stables que les versions de production.
Si vous voulez utiliser les toutes dernières sources, qui contiennent tous les patches courants, et les corrections de bogues, vous pouvez utiliser notre entrepôt BitKeeper. Il n'y a pas de ``versions'' en tant que telle, mais des paquets, sur lesquels le code futur est basé.
La politique de nommage de MySQL utilise des numéros de
version qui consiste en trois nombres suivis d'un suffixe. Par
exemple, une version nommée
mysql-3.21.17-beta
doit être interprétée
de la fa¸on suivante :
Le premier nombre (3
) décrit le format
de fichier. Toutes les versions 3 ont le même format de
fichier.
Le second nombre (21
) correspond au
niveau de version. Normalement, il y a le choix entre deux
d'entre eux. L'un correspond à la version/branche stable
(actuellement 23
) et l'autre se
réfère à la branche de développement (actuellement
4.0
). Normalement, les deux versions
sont stables, mais la version de développement peut
comporter des lacunes, manquer de documentation sur des
nouvelles fonctionnalités, ou peut ne pas compiler sur
certains systèmes.
Le troisième nombre (17
) est le
numéro de version au sein du niveau de version. Celui-ci
est incrémenté à chaque nouvelle publication. En temps
normal, vous souhaiterez utiliser la dernière version du
niveau de version que vous avez choisi.
Pour chaque modification mineure, le dernier nombre de la version est incrémenté. Lorsque les nouvelles fonctionnalités sont majeures, ou que des incompatibilités mineures apparaissent avec les anciennes versions, le deuxième chiffre est incrémenté. Lorsque le format de fichier change, le premier chiffre est incrémenté.
Les noms de versions inclut aussi un suffixe qui indique le niveau de stabilité de la version. Une série progresse avec différents suffixes, qui indique sa stabilité. Les suffixes possibles sont :
alpha
indique que la publication
contient de grandes portions de nouveau code qui n'a pas
été testé à 100%. Les bogues connus (d'ordinaire, il
n'y en a aucun) doivent être documentés dans la section
nouveautés. See Annexe C, Historique des changements MySQL. Il existe aussi
de nouvelles commandes et extensions dans la plupart des
versions alpha. Du développement actif qui inclut des
changements majeurs dans le code peut concerner les
versions alpha, mais tout sera testé avant de faire une
publication. Il ne devrait pas y avoir de bogues connus
dans les publications de MySQL.
beta
signifie que tout le nouveau code
a été testé. Aucune fonctionnalité majeure qui
pourrait causer corruption du code n'est ajoutée. Il ne
doit pas y avoir un seul bogue connu. Une version alpha
passe en beta
quand il n'y a pas eu de
bogue fatal rapporté depuis au moins un mois et que nous
ne prévoyons pas de nouvelle fonctionnalité qui pourrait
corrompre d'anciennes commandes.
gamma
est une version bêta qui existe
depuis un certain temps et qui semble fonctionner
correctement. Seulement des changements mineurs sont
effectués. C'est ce que de nombreuses autres compagnies
appellent une publication.
S'il n'y a pas de suffixe, cela signifie que la version fonctionne depuis un certain temps sur différents sites avec aucun rapport de bogue autre que des bogues spécifiques à une plate-forme. Seuls des corrections critiques sont appliquées à la publication. C'est ce que l'on appelle une version stable.
MySQL utilise un schéma de nommage qui est légèrement différent des autres produits. En général, il est plutôt sûr d'utiliser une des versions qui est disponible depuis quelques semaines, sans avoir été remplacée par une nouvelle version de la même série.
Toutes les versions de MySQL passent par nos tests et bancs d'essais standards pour nous assurer qu'elles peuvent être utilisées sans danger. Les séries de tests s'améliorent en permanence car les tests standards sont étendus dans le temps pour traquer tous les bogues précédemment trouvées.
Notez bien que toutes les versions de MySQL ont été testées au moins avec :
Une batterie de tests internes
Le dossier mysql-test
contient de
nombreux cas de tests.
Nous utilisons ces tests pour virtuellement tous les systèmes d'exploitation. Voyez Section 27.1.2, « Suite de test de MySQL » pour plus d'informations sur ces fichiers.
Les bancs de tests MySQL
Ils effectuent une série de requêtes communes. C'est aussi un test pour savoir si le dernier processus d'optimisation rend le code plus rapide. See Section 7.1.4, « La suite de tests MySQL ».
Le test crash-me
Il tente de déterminer de quelles fonctionnalités disposent les bases de données et quelles en sont les limites. See Section 7.1.4, « La suite de tests MySQL ».
Un autre test provient du fait que nous avons la version la plus récente de MySQL dans notre propre environnement de production interne, sur au moins une machine. Nous avons plus de 100 Go de données à manipuler.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.