# Proposition pour le versioning git L'objectif de ce document est d'offrir une nouvelle proposition concernant la structure des branches dans Lunatic. ## Problème actuel Lunatic se base sur la structure git flow avec une branche `develop` qui accueille les développement des différentes fonctionnalités. Cette branche est ensuite fusionné avec `main` lorsque l'on décide d'une montée en version. Cette approche pose plusieurs problèmes dans le cadre de Lunatic : - Il est difficile de déterminer quand fusionner dans `main` vu que developpement est en évolution constante - Il n'est pas possible de corriger un bug sur une version antérieur de Lunatic - Develop se retrouve parfois désynchro avec `main` et un rebase casse les MR associées. ## Proposition Après observation de dépôt open source une autre approche apparait comme intéréssante ([react](https://github.com/facebook/react), [symfony](https://github.com/symfony/symfony)) avec un système de branche basé sur le numéro de version mineur de Lunatic. ![Une branche par version](https://hackmd.io/_uploads/HkZFcMela.png) ### Fonctionnement On commence par créer une branche pour le numéro de version mineur actuel `2.6`. Lorsque l'on décide d'attaquer un nouveau sprint avec de nouvelles fonctionnalité on déclenche la création d'une nouvelle branche (ici `2.7`) qui accueillera les développements lié à cette nouvelle version. Les branches de version évoluent ensuite de manière indépendante (cela permet par exemple de venir publier une version `2.6.1`, `2.6.2` pour des hotfix pendant que la `2.7` continue d'évoluter). #### Comment synchroniser ? Les nouvelles branches ont besoin de récupérer les modifications faites sur les branches plus anciennes (un même hotfix doit être récupéré par plusieurs branches). Dans ce cas là, un commit de merge permet d'ajouter les nouveaux commits depuis une autre branche (on ne rebase pas). ![Merge pour récupérer les fix](https://hackmd.io/_uploads/rJE8Xflxa.png) #### Montée de version ? Lors du travail sur une branche la montée de version se fait via des commits dédiés. ![bump version](https://hackmd.io/_uploads/SyoxSMgep.png) #### Gérer les PR Lors du travail sur une nouvelle version les PR peuvent se faire à la fois sur la version publiée et sont ensuite récupéré au travers d'un merge request sur les versions plus récentes. Par exemple : - Un bug est repéré sur la `2.6.0` - On corrige le bug sur la branche `2.6` et on crée une release `2.6.1` - On crée une commit de merge pour récupérer les changement sur la branche `2.7` et les branches plus avancé si il y en a. #### Gestion d'une LTS (Long term support) Ce système de branche peut aussi permettre d'envisager une version de Lunatic en LTS (long term support) qui ne recevrait pas de nouvelle fonctionnalités mais des corrections de bugs (une version stable) pendant une durée définie à l'avance.