La version 5.0 de la base de données MySQL est sortie en version stable en octobre 2005. Cela faisait donc plus de 3 ans que les utilisateurs attendaient une nouvelle version stable et le bébé est arrivé le 27 novembre dernier (en version 5.1.30) en apportant pas mal de nouveautés.br / a href=http://www.heise-online.co.uk/open/features/print/112097Cet article très complet/a du site Heise Online décrit les principales (partitions des bases sur plusieurs disques, gestionnaire d'évènements, amélioration des fonctions de réplication, log dans les tables, etc).br / br / Tout semble donc bien aller dans le petit monde de MySQL. Certes la nouvelle version s'est faite attendre et ce n'est qu'une version intermédiaire avant le grand saut de la version 6.0 (qui sera basée sur a href=http://dev.mysql.com/tech-resources/articles/falcon-in-depth.htmlFalcon/a) mais après tout une base de données est un composant critique et il vaut mieux prendre le temps de proposer un produit stable. Même si cela prend plus de trois ans.br / br / L'ennui se situe justement là. Selon a href=http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.htmlun article/a posté sur le blog du créateur de MySQL (Michael Widenius) cette version est bourrée de bugs critiques !br / br / Alors que la 5.1 n'est qu'une version d'attente de la 6.0 et qu'elle doit donc ne proposer que des nouveautés sans risques et traquer les bugs c'est le contraire qui est constaté par M. Widenius. On trouve dans son post des phrases comme :br / * Ne vous attendez pas à ce que tous les bugs critiques que vous aviez rencontré dans la 5.0 soient corrigés dans la 5.1.br / * Si vous projetez d'utiliser les nouveautés de MySQL 5.1 alors considérez ces fonctions comme étant en qualité béta.br / * Nous avons encore 20 bugs connus provoquant des crashs et des résultats erronés dans la 5.1. Et 35 bugs de plus si on ajoute ceux de la 5.0 qui doivent toujours être présents dans la 5.1. Nous avons également encore plus de 180 bugs sérieux (P2) dans la 5.1.br / * Concernant les nouveautés si vous avez un crash d'une table partitionnée alors il est très difficile (parfois impossible) de la réparer.br / * Si vous avez un crash serveur pendant un ALTER TABLE sur une table partitionnée alors vous pouvez perdre toutes les données de cette table.br / * Le log dans les tables est si lent (-30%) que la fonction est inutilisable pour les sites chargés.br / br / D'après Widenius il y a plusieurs explications à la sortie de cette version pleine de bugs bloquants. D'après lui ce sont les managers et pas les ingénieurs qui prennent les décisions de sortie en fonction d'un planning prédéfini et pas en fonction de la qualité réelle du code. Les équipes ont été éclatés en plusieurs teams et de nombreux core developpers on quitté la boite depuis le rachat par Sun. La communauté n'est pas incluse dans le processus de test et elle ne peut pas vraiment remonter les bugs lors du développement.br / Widenieus ne critique pas Sun et il déclare même que la faute revient exclusivement au management de MySQL. La seule faute de Sun serait de ne pas avoir changé l'organisation pour corriger les dysfonctionnements. Il plaide finalement pour un mode de fonctionnement proche de celui de postgreSQL ou la communauté à un rôle moteur dans ce qui est fait et décidé.