2.1.2.4 Politique de publication : aucun bug connu dans les versions

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 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.

• 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. Erreurs connues et manques 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. Les listes de diffusion 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.