Nous mettons beaucoup d'efforts et de temps à la publication de version sans bugs. A notre connaissance, nous n'avons jamais publié une version de MySQL qui contienne un bug fatal connu et reproductible.
Un bug fatal est un problème qui fait planter MySQL en utilisation normale, fournit des réponses erronées à des requêtes classiques, ou a des problèmes de sécurité.
Nous documentons tous les problèmes ouverts, bugs et tout ce qui dépend des choix de conceptions. See Section 1.5.7, « Erreurs connues, et limitations de MySQL ».
Nous avons pour but de corriger tout ce qui peut être corrigé, sans risquer la stabilité des versions de MySQL. Dans certains cas, cela signifie que nous pouvons corriger une erreur dans la version de développement, mais pas dans la version stable. Naturellement, nous documentons ces problèmes, pour que les utilisateurs soient avertis.
Voici une description de notre processus de publication :
Nous surveillons les bugs sur les listes de support utilisateur, les listes externes et la base de données de bugs sur le site http://bugs.mysql.com/.
Tous les bugs rapportés pour les versions en production entrent dans la base de données des bugs.
Lorsque nous corrigeons un bug, nous essayons de réaliser un cas de test, que nous incluons dans notre système de tests, pour nous assurer que le bugs ne reviendra jamais (environ 90% des bugs ont des cas de tests).
Nous créons aussi des cas de tests pour toutes les nouvelles fonctionnalités que nous voulons ajouter à MySQL.
Avant de commencer à compiler une nouvelle version de MySQL, nous nous assurons que tous les bugs reproductibles pour les versions anciennes (3.23.x, 4.0.x, etc...) sont corrigés. Si le bug ne peut être corrigé (pour des raisons de choix de conception), nous le documentons dans le manuel. See Section 1.5.7, « Erreurs connues, et limitations de MySQL ».
Nous compilons MySQL sur toutes les plates-formes pour lesquelles nous distribuons des paquets binaires (plus de 15 plates-formes à ce jour), et nous exécutons notre suite de tests et notre suite de performances sur chacune d'entre elles.
Nous ne publions pas un paquet binaire sur une plate-forme pour laquelle la suite de test ou de performances échoue. Si c'est une erreur générale, nous la corrigeons, et nous recommen¸ons les tests sur toutes les plates-formes, à partir de zéro.
Si nous recevons, durant le temps de compilation et de tests qui peut prendre deux à trois jours, un rapport de bugs concernant un bug fatal (par exemple, un bogue qui crée un coredump), nous le corrigeons, et nous recommen¸ons le processus de tests.
Après avoir publié les paquets binaires sur
http://www.mysql.com/, nous envoyons une annonce par email
aux listes de diffusion. See
Section 1.4.1.1, « Les listes de diffusion de MySQL ». Le message d'annonce
contient une liste de toutes les changements de la
version, et de tous les bugs connus. La section des
problèmes connus, ‘known
problems
’, dans les notes de publications
n'a été utilisé que dans quelques versions.
Pour donner rapidement accès aux dernières fonctionnalités de MySQL, nous réalisons une publication de MySQL toutes les 4 à 5 semaines. http://downloads.mysql.com/snapshots.php.
Si, après une publication, nous recevons des rapports de
bugs qui prouvent qu'il y a, malgré tout, un bug critique
dans une version spécifique à une plate-forme, nous le
corrigeons rapidement, et nous annon¸ons une version
'a'
pour la plate-forme. Grâce à
notre large communauté d'utilisateurs, les problèmes
sont trouvés rapidement.
Nos résultats de bonne publication sont excellents. Dans
les dernières 150 versions, nous avons dû reprendre la
compilation moins de 10 fois (dans trois des cas, le bug
était dû à glibc
sur l'une de nos
machines de tests, qu'il a été difficile de trouver.
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.