Marien Fressinaud Le blog

Lessy : versions et itérations

Cet article fait partie d’une série. Retrouvez les autres articles dans « Lessy’s more ».

Le 29 octobre 2017.

Je me suis intéressé ces derniers jours au système de sortie des nouvelles versions de Lessy. Cela peut paraître étonnant, mais décider d’un tel système est parfois compliqué et pose plusieurs problèmes.

Pour commencer, on peut se poser la question « pourquoi versionner ? ». J’y vois personnellement quatre intérets en particulier :

Lorsque je travaillais encore sur FreshRSS, nous nous étions souciés de la question de la visibilité. Nous avions alors trois versions distinctes : une stable, sortant à intervalles plutôt longs, la bêta qui sortait tous les… hum… deux mois (?) et la version de développement. Nous avions décidé de mettre en avant la version bêta qui était alors moins testée que la version stable mais qui avait l’avantage de garder les utilisateurs accrochés à « l’actualité » de FreshRSS. Ce système avait toutefois le désavantage d’être lourd à maintenir. Je souhaitais par conséquent un système plus simple pour Lessy tout en continuant de mettre en avant le travail quotidien effectué.

Concernant le deuxième point, à savoir que le versionnage donne une indication sur le niveau de modifications depuis la version précédente, je pense évidemment au système « semantic versioning ». Si ce système possède un intéret évident dans le cas de dépendances (ex. le logiciel A dépend du logiciel B dans sa version X), je ne le vois pas dans le cas d’un logiciel en « bout de chaine » tel que Lessy. C’est pourquoi je suis parti sur un système de nommage totalement différent.

La raison consistant à donner des numéros de version pour permettre de revenir en arrière en cas de soucis me paraît évidemment légitime bien que le cas se présente à mon avis de façon assez rare.

Enfin, sortir une nouvelle version est loin d’être uniquement une tâche technique. Il s’agit avant tout de fêter une nouvelle étape franchie dans le développement et de marquer d’une pierre blanche l’avancement pour pouvoir constater plus tard tout le chemin parcouru. Célébrer une nouvelle version, ça motive énormément !

Concrêtement, comment cela va-t-il se passer pour Lessy ?

L’ensemble des tâches à effectuer (fonctionnalités, tâches techniques, corrections de bugs, etc.) sont listées en vrac dans les tickets GitHub, ce qui me sert par conséquent de boite d’entrée. Ces tâches sont ensuite triées par petits groupes au sein d’itérations représentées par les projets GitHub. Les tâches d’une itération forment un ensemble de fonctionnalités ou tâches techniques similaires et leur temps de développement total effectif ne doit pas être excessif (je me fixe 2 ou 3 semaines comme maximum). Ces itérations permettent ainsi de dessiner une pseudo feuille de route du projet. Et comme chacune d’entre elles est nommée (d’après les constellations astronomiques), la fin d’une itération donne son nom à une nouvelle version de Lessy.

Ainsi, des quatre points que je listais plus haut, seule la problématique des dépendances n’est pas du tout adressée. Pour les trois autres :

Pour terminer, si j’ai choisi de nommer les versions de Lessy par les noms des constellations astronomiques, c’est avant tout parce que je cherchais un système de nommage original permettant de penser à autre chose qu’à seulement du code. Comme lever le nez du clavier ne suffit pas toujours à se changer les idées, je me disais que le lever vers le ciel serait une bonne idée.

Cet article fait partie de la série « Lessy’s more ».

Retourner au blog