Cycles de développement de YACS
Pour s'y retrouver dans les numéros de versions
Le projet YACS fait appel aux méthodes les plus modernes de développement de logiciel, issues de l'eXtreme Programming (XP) et du manifesto Agile.
En clair, tout ceci va vite, très vite même, et les cycles de développement s'organisent comme suit :
[*] Tous les 30 jours environ, l'équipe de développement, d'intégration et de traduction livre une version stabilisée, dont le numéro est constituée de l'année et du mois. Par exemple, la 7.4, c'est la version du mois d'avril 2007.
[*] En début de cycle, sur deux à trois semaines, porte le principal effort de développement, pour introduire de nouvelles fonctions et faire évoluer YACS. Ceci donne lieu à des versions alpha, numérotées d'après le jour de sortie dans le mois. Par exemple, la version 7.4alpha16 a été générée le 16 avril 2007, et, puisque c'est une version alpha, elle ne doit pas être mise en production. Normalement, les versions alpha montrent l'avancement des développements, mais restent incomplètes (traductions absentes, pas d'outil de migration des serveurs existants).
[*] En milieu de cycle, on passe principalement à l'intégration et à la correction de bugs. Ceci donne lieu à des versions béta, également numérotées d'après le jour de sortie dans le mois. Les versions béta peuvent être utilisées en production, mais avec le risque de découvrir une régression fonctionnelle ou autre bug.
[*] En fin de cycle, une archive officielle est livrée, dépourvue de mention alpha et béta, et c'est celle qui devient conseillée pour l'installation des nouveaux serveurs.
Cette façon de procèder optimise considérablement les efforts de l'équipe, parce qu'elle intégre les développements et les corrections de bug, au lieu de les opposer. Dans une équipe classique, sur des cycles de 3 ou 5 mois, il y a d'un côté des développeurs qui tracent la route, et, derrière, d'autres développeurs qui rament avec les bugs. D'où le besoin de gérer des branches de logiciels divergentes, de les réconcilier périodiquement, etc. Avec au final, beaucoup d'énergie partie en fumée juste pour maintenir la dynamique.
Avec YACS, on fait l'inverse. Le but est d'utiliser au mieux les ressources existantes, quitte à fractionner les évolutions importantes sur plusieurs versions. Ceux qui développent sont aussi ceux qui corrigent les bugs, ça évite les grosses têtes. Et pour chercher la bonne version, c'est forcément la plus récente, c'est pas compliqué...
En clair, tout ceci va vite, très vite même, et les cycles de développement s'organisent comme suit :
[*] Tous les 30 jours environ, l'équipe de développement, d'intégration et de traduction livre une version stabilisée, dont le numéro est constituée de l'année et du mois. Par exemple, la 7.4, c'est la version du mois d'avril 2007.
[*] En début de cycle, sur deux à trois semaines, porte le principal effort de développement, pour introduire de nouvelles fonctions et faire évoluer YACS. Ceci donne lieu à des versions alpha, numérotées d'après le jour de sortie dans le mois. Par exemple, la version 7.4alpha16 a été générée le 16 avril 2007, et, puisque c'est une version alpha, elle ne doit pas être mise en production. Normalement, les versions alpha montrent l'avancement des développements, mais restent incomplètes (traductions absentes, pas d'outil de migration des serveurs existants).
[*] En milieu de cycle, on passe principalement à l'intégration et à la correction de bugs. Ceci donne lieu à des versions béta, également numérotées d'après le jour de sortie dans le mois. Les versions béta peuvent être utilisées en production, mais avec le risque de découvrir une régression fonctionnelle ou autre bug.
[*] En fin de cycle, une archive officielle est livrée, dépourvue de mention alpha et béta, et c'est celle qui devient conseillée pour l'installation des nouveaux serveurs.
Cette façon de procèder optimise considérablement les efforts de l'équipe, parce qu'elle intégre les développements et les corrections de bug, au lieu de les opposer. Dans une équipe classique, sur des cycles de 3 ou 5 mois, il y a d'un côté des développeurs qui tracent la route, et, derrière, d'autres développeurs qui rament avec les bugs. D'où le besoin de gérer des branches de logiciels divergentes, de les réconcilier périodiquement, etc. Avec au final, beaucoup d'énergie partie en fumée juste pour maintenir la dynamique.
Avec YACS, on fait l'inverse. Le but est d'utiliser au mieux les ressources existantes, quitte à fractionner les évolutions importantes sur plusieurs versions. Ceux qui développent sont aussi ceux qui corrigent les bugs, ça évite les grosses têtes. Et pour chercher la bonne version, c'est forcément la plus récente, c'est pas compliqué...