Pour mon framework, depuis longtemps je voulais y intégrer un système d'installation automatique, qui permette d'installer, d'initialiser (mise à jour de la base de données, de la configuration de l'application...) un module, et aussi de le mettre à jour très facilement.

Au début de l'été 2009, j'ai donc commencé à développer ce nouveau système d'installation de module. Quand j'ai commencé, je pensais que je n'en aurais pas pour longtemps. J'ai donc commencé à commiter les modifications... dans le trunk. Mais plus j'avançais, plus je découvrais des problèmes à résoudre. Et puis une fois qu'il était opérationnel, j'ai découvert à l'usage d'autres soucis, qu'il a fallu corriger. Tout ceci a pris au final beaucoup de temps. En ajoutant les longues périodes où j'étais trop occupé sur d'autres projets, le système d'installation a commencé à être stable qu'en juin dernier !

Parallèlement à ça, j'ai amélioré d'autres composants, des contributeurs ont proposé de nombreux patchs correctifs ou de nouvelles fonctionnalités, tout ça commité... aussi dans le trunk...

Bref, le trunk contenait à la fois des nouveautés et corrections diverses et variées, mais aussi un composant expérimental. Et ce composant impactant le fonctionnement interne du framework, il n'était pas possible de sortir des versions intermédiaires pour que les utilisateurs puissent profiter des nouveautés autre que ce système d'installation. Créer une branche à partir d'un "changeset" antérieur aux premiers commits du système d'installation, en y backportant les autres modifications, ou faire un "backout" de tous les changements apportés par le système d'installation, aurait demandé trop de travail, à l'époque où je me suis rendu compte de mon erreur.

D'habitude, j'essaye toujours d'avoir un trunk "stable", fonctionnel. Mais la sous-estimation du travail sur ce nouveau composant, l'envi de l'intégrer à la prochaine version, et certainement l'enthousiasme que j'avais à le développer, ont fait que je n'ai pas vraiment réfléchi à l'organisation de ce développement. Et au final le trunk a souvent été inutilisable durant cette période. Et je n'ai pas vraiment d'excuses, dans la mesure ou brancher et merger avec Mercurial (ou Git) ne pose en général peu de problèmes (ce n'est pas le cas avec subversion, ça n'a jamais vraiment fonctionner avec moi).

J'aurais donc du développer ce système d'installation dans une branche à part, laissant sur le trunk que les corrections de bugs et améliorations sur les autres parties de jelix. Ça aurait permis de sortir des versions intermédiaires de Jelix à partir du trunk, qui soient opérationnelles (et sans le système d'installation) . Et j'aurais pu continuer le développement du système d'installation dans son coin, pour ensuite intégrer les modifications de cette branche dans le trunk une fois qu'il était utilisable.

Les prochains gros chantiers sur Jelix seront donc développés dans des branches, afin de pouvoir sortir des versions stables de jelix plus régulièrement :-)