J'ai actuellement l'impression que de nombreux projets libres changent leur politique de planning de sortie des branches. Cela concerne généralement des gros projets sur une autre échelle de grandeur que PhpWebGallery, mais s'inspirer des réflexion des équipes de ces gros projets ne peut pas faire de mal :-)

Auparavant, les projets sortaient des nouvelles branches contenant des évolutions lorsque toutes les évolutions attendues ou prévues dans la "roadmap fonctionnelle" étaient prêtes. Cette politique peut conduire à une attente énormément longue, parfois sujette à de nombreux trolls, comme pour le projet Debian.

Aujourd'hui, cette politique de migration a tendance à passer sur un modèle à date prévue et fixes. Par exemple, KDE et Ubuntu fonctionnent sur ce principe. Or, mon expérience professionnelle et mes lectures orientés qualité logiciel m'ont enseignées que 3 éléments devaient se distinguer : la qualité, les fonctionnalités, le délai.

Sur la livraison d'une nouvelle version d'un logiciel, l'erreur commise par beaucoup d'éditeur est de vouloir assurer ces 3 points. Or, c'est impossible. En choisir 2 parmi les 3 est tout à fait tenable, mais pas 3. En traduisant pour la politique de livraison d'un logiciel, on peut dire que livrer à date fixe revient à choisir {qualité,délai} et que livrer lorsque les fonctionnalités sont prêtes revient à choisir le couple {qualité,fonctionnalités}.

Dans les 2 modèles, on retrouve la qualité. C'est indispensable. Livrer des fonctionnalités qui ne fonctionnent pas de manière considérée stable revient à assassiner son projet. Dans le cas des logiciels libres, la plupart du temps, les éditeurs ont la chance de ne pas être tenus à l'impossible par un client : réunir à la fois qualité, fonctionnalités et délai. Profitons-en.

Cette petite réflexion me mène à la conclusion que pour la sortie de la branche 1.5, j'aimerais tenter la sortie à date prévue. Le 15 septembre 2005 par exemple (ça ferait 6 mois par rapport à la sortie de la 1.4).