Dans le projet Koha (mais il dispose peut-être de plus de volontaires
puisque c'est un projet 100% international, et anglophone), je crois que
nous avons trouvé un bon équilibre :
* Un release manager est nommé pour une version X.
* Tout le monde dit ce qu'il aimerait voir dans la version. On cherche
les volontaires et/ou les financeurs, et on voit ce que l'on peut mettre
dans quel délai. On essaye de faire la part entre le délai et le
contenu. A un moment, le release manager décide d'une date, et donc du
contenu fonctionnel de la version.
* On a donc un contenu et une date. Qu'on essaye de respecter, et que,
comme dans tous les projets informatiques, on respecte sans aucun retard :D
* On sort des versions publiques instables (avec le même principe de
numérotation que pour le noyau linux), puis des RC (Release Candidate).
Lorsque 3 ou 4 bibs utilisent l'appli en production, on sort une version
officiellement stable.
sur la version 2.2.0 de Koha, on a eu :
* 2.1.0, 2.1.1, 2.1.2, 2.1.3 en instable
* 2.2.0RC1 => 2.2.0RC4 en stable mais attention (les RC permettent aussi
de prendre le temps pour les traductions)
* 2.2.0
Il reste dans la 2.2.0 quelques bugs. Donc on va sortir une 2.2.1 début
février.
Au niveau fonctionnel, on se permet d'ajouter des fonctionnalités qui ne
changent rien dans la structure de la BD sur une version 2.2.x. Le
Release Maintainer peut décider d'intégrer une petite modif dans la BD
sur une 2.2.x. Et toute grosse modif est reportée sur la prochaine
version majeure (2.4, c'est la branche HEAD dans le CVS)
voili voilou, c'était notre expérience autour de Koha
(je précise que j'ai été Release Manager pour la 2.0, puis Release
Manager pour la 2.2, et maintenant Release Maintainer pour la 2.2. C'est
un argentin qui est Release Manager pour la 2.4, et un anglais qui était
Release Maintainer pour la 2.0)