Kaj Arnö annonce par le biais de son blogue, un changement important dans la politique de publication du code source 'Entreprise' de MySQL.
Les nouvelles fonctionnalités sont désormais envoyées directement dans les nouvelles versions. MySQL s'engage à faire au moins 2 mises à jour de la version de production (dite GA) par an, en fonction des alertes de sécurité qui seront identifiées.
Les versions MySQL seront mises à jour tous les mois jusqu'à ce que la compagnie décide que cette version est mature : dans ce cas, le rythme de mise à jour baissera considérablement.
Les sources de la version Entreprise ne sont plus publiées.
Dans l'ensemble, le processus de publication se clarifie, ce qui est bon : les versions très stables n'ont plus que des corrections de bogues et sécurité. Les nouvelles fonctionnalités sont repoussées à la version de développement, et les versions de productions initiales, qui auront la plus forte charge de tests, seront mises à jour mensuellement.
Deux points plus sensibles sont à relever. Les sources de la version Entreprise sont retirées. Cela ne fait qu'ajouter un obstacle sur la rue, puisque la GPL permet à n'importe quel client de publier ce code librement. Le code était déjà bien caché dans le ftp de MySQL, mais il est encore plus loin maintenant.
Les nouvelles fonctionnalités et contributions de la communauté sont repoussées à la versions de développement actuelle. Nous sommes rendus à la version 5.0 en GA, et la version 5.1 (qui arrive sous peu), est en béta : en fait, les nouvelles contributions sont repoussées à la version 5.2/6.0, et n'apparaîtront pas avant ... longtemps. Très longtemps.
La communauté des contributeurs au code réagit fortement à ces annonces. Peter Zaitsev indique qu'il a un patch de micro-secondes pour les slow query qui attend encore, alors que Jeremy Cole a recu un traitement de faveur pour son SHOW profile. Tous ces contributeurs ayant pignon sur rue, montent au créneau pour défendre leur travail.
En regardant de plus loin, il semble que la communauté soit incitée à travailler sur les versions récentes uniquement. Plus la version du serveur est stable (beta, GA, mature GA), plus les versions sont rares. Les versions payantes sont ainsi réservées à ceux qui ne connaissent pas bien MySQL : ce sont eux qui iront chercher les mature GA ou les versions entreprise, pour se prémunir d'un bug possible.
La communauté ne paie pas cher, mais court les risques. Les clients paient peu cher, mais s'assure contre les bogues. Est-ce un modèle viable pour votre entreprise ?
Avec un rythme de mise à jour annuel des serveurs (qui donc utilise encore une version 4 ?), cette nouvelle politique devrait avoir un faible impact sur une installation en production. Les nouvelles fonctionnalités seront reportées à l'année d'après, et il ne reste que le cas des bogues teigneux à corriger : avoir besoin d'une correction spécifique va devenir compliqué, ou cher, ou les deux.
Enfin, la disparition des codes sources entreprise sont surtout des sujets politiques : tant qu'on est pas impacté par un bogue, on va facilement en sauter quelques versions. Mais c'est dommage de voir ce point mis tout à la fin, et publié en pleines vacances : on dirait une vieille manipulation politique ou commerciale, alors que ça n'en est pas.
- Communication Challenges for the MySQL Community Team
- Refining MySQL Community Server
- MySQL Takes Another Step (Away from Open Source)
- On MySQLs Commitment to Open Source
- Refining MySQL Community Server
- Refining MySQL Community Server (2)
- DorsalSource
- MySQL Community split officially a failure
- New MySQL Community Release Policies published
- The Importance of Being Earnest
- Tension Grows Between MySQL AB and the Open Source Community
Les nouvelles fonctionnalités sont désormais envoyées directement dans les nouvelles versions. MySQL s'engage à faire au moins 2 mises à jour de la version de production (dite GA) par an, en fonction des alertes de sécurité qui seront identifiées.
Les versions MySQL seront mises à jour tous les mois jusqu'à ce que la compagnie décide que cette version est mature : dans ce cas, le rythme de mise à jour baissera considérablement.
Les sources de la version Entreprise ne sont plus publiées.
Dans l'ensemble, le processus de publication se clarifie, ce qui est bon : les versions très stables n'ont plus que des corrections de bogues et sécurité. Les nouvelles fonctionnalités sont repoussées à la version de développement, et les versions de productions initiales, qui auront la plus forte charge de tests, seront mises à jour mensuellement.
Deux points plus sensibles sont à relever. Les sources de la version Entreprise sont retirées. Cela ne fait qu'ajouter un obstacle sur la rue, puisque la GPL permet à n'importe quel client de publier ce code librement. Le code était déjà bien caché dans le ftp de MySQL, mais il est encore plus loin maintenant.
Les nouvelles fonctionnalités et contributions de la communauté sont repoussées à la versions de développement actuelle. Nous sommes rendus à la version 5.0 en GA, et la version 5.1 (qui arrive sous peu), est en béta : en fait, les nouvelles contributions sont repoussées à la version 5.2/6.0, et n'apparaîtront pas avant ... longtemps. Très longtemps.
La communauté des contributeurs au code réagit fortement à ces annonces. Peter Zaitsev indique qu'il a un patch de micro-secondes pour les slow query qui attend encore, alors que Jeremy Cole a recu un traitement de faveur pour son SHOW profile. Tous ces contributeurs ayant pignon sur rue, montent au créneau pour défendre leur travail.
En regardant de plus loin, il semble que la communauté soit incitée à travailler sur les versions récentes uniquement. Plus la version du serveur est stable (beta, GA, mature GA), plus les versions sont rares. Les versions payantes sont ainsi réservées à ceux qui ne connaissent pas bien MySQL : ce sont eux qui iront chercher les mature GA ou les versions entreprise, pour se prémunir d'un bug possible.
La communauté ne paie pas cher, mais court les risques. Les clients paient peu cher, mais s'assure contre les bogues. Est-ce un modèle viable pour votre entreprise ?
Avec un rythme de mise à jour annuel des serveurs (qui donc utilise encore une version 4 ?), cette nouvelle politique devrait avoir un faible impact sur une installation en production. Les nouvelles fonctionnalités seront reportées à l'année d'après, et il ne reste que le cas des bogues teigneux à corriger : avoir besoin d'une correction spécifique va devenir compliqué, ou cher, ou les deux.
Enfin, la disparition des codes sources entreprise sont surtout des sujets politiques : tant qu'on est pas impacté par un bogue, on va facilement en sauter quelques versions. Mais c'est dommage de voir ce point mis tout à la fin, et publié en pleines vacances : on dirait une vieille manipulation politique ou commerciale, alors que ça n'en est pas.
- Communication Challenges for the MySQL Community Team
- Refining MySQL Community Server
- MySQL Takes Another Step (Away from Open Source)
- On MySQLs Commitment to Open Source
- Refining MySQL Community Server
- Refining MySQL Community Server (2)
- DorsalSource
- MySQL Community split officially a failure
- New MySQL Community Release Policies published
- The Importance of Being Earnest
- Tension Grows Between MySQL AB and the Open Source Community
-
Auteur
