# Procédure de MàJ de Flow
<br>

Communiquer au client et savoir quand on été ajoutée des choses au projet, cela apporte un sentiment de valeur ajoutée et de vie autour du projet. Le côté historique est également précieux lorsque l'on parle de choses datant de plusieurs mois voire années.

**CHANGELOG août 2020 :** https://hackmd.io/7FXzU78iQ2yYVofi0N47Pw?both

## Incrémentation des versions de Flow

Principe de base résumé par cette image :

**Version Majeure :**
Flow est à sa version 3 car la version majeure suit celle de CodeIgniter. On conserve ça.

**Version Mineure :**
On incrémente une version mineure à chaque release. Dans le cas de Flow il est difficile de faire des déploiements sur une quinzaine de jour sachant que ce ne sont pas tous les clients qui suivent une roadmap, des roadmaps croisées, et des une organisation tout simplement pas faite en réelle itération comme on observe dans le cas des méthodes agiles. Cela donnerait lieu chez nous à une version 3.350 par exemple très très vite.
**Dans le cas de Flow on choisira des itérations mensuelles** chaque itération donnant lieu en début de mois à une communication des apports faits sur le mois passé, les corrections etc. Ce que fait VS Code par exemple. Chez nous ce sera un point communication à marquer, un client n'est pas forcément au courant de ce qui a été fait à certains endroits, du moment que cela a été fait pour le compte d'un autre client.

**Version de Patch :**
Version qu'on pourrait utiliser mais qui risque de trop alourdir les procédures de merges et déploiements. Ce sera à utiliser plus tyard peut-être.

## Process Git

Pour mener ça à bien on pourrait mettre en place une branche develop. Le but étant de merger sur master uniquement quand nécessaire donc pour :
* bugs vraiments bloquants et soucis de perf nécessitant un merge immédiat
* R&D et autres améliorations n'ayant pas de délais et donc pouvant être mergée en fin de mois

On fera exception à cela pour les clients : on prendra comme branche de départ master directement, le déploiement devant être déployé au plus tôt on incrémentera la version patch dans ce cas là uniquement.

En plus de ça il faudra mettre en place un système de tags Git pour suivre les "normes" et pouvoir se placer sur une version pour tester etc.
Pour faciliter le déploiement et les tags on aura mis en place un script qui pourrait nous faire de manière automatique le tag lors d'un merge.
On utilisera peut-être également les "milestone" de Gitlab pour associer les MR à une itération mensuelle.

Pour garder un historique d version propre il sera peut-être nécessaire de se mettre à utiliser le `git rebase`.
<br>
***En vert :** Master.*
***En gris :** Développement générique pour un client -> merge ASAP et master en branche de départ. On rappatriera cette branche sur develop également, à partir de master.*
***En orange :** Develop.*
***En bleu :** Nouvelle fonctionnalité, hotfix, à l'initiative de Nateev et/ou pouvant attendre la fin de release menseulle.*
***En jaune :** Mal illustré ici, une fonctionnalité ayant pour base develop, devenue urgente et nécessitant un merge avant la fin de release.*
*Utilité du git rebase*

## Process organisationnel

L'édition des tags ne se fait pas par le développeur de la branche mais par le développeur qui va merger la branche. On fera ça via un script qui merge develop sur master et fait le tag automatiquement selon la dernière version dans le fichier CHANGELOG.md. Cela évite les commits incessants de MàJ de la version et du MD.
Les développements spécifiques n'impacteront pas les version car ils ont pour branche d'origine un thème donné, et nous n'aurons pas de version pour les thèmes.

Ormis les tags en plus, le processus de merge ne change pas pour Flow, la branche par défaut sera `develop` sur ce projet. Il faudra changer de branche de référence exprès pour un client pour merger directement sur `master`. Seuls les lead dev pourront merger sur `develop`, comme c'est le cas actuellement sur `master` et devront avant cela ajouter une ligne au fichier changelog.md.

## Le changelog

Nous allons suivre tout ce qui est recommandé sur [ce lien](https://keepachangelog.com/en/1.0.0/) à l'exception de la mention des contributeurs. A minima on retrouvera "nouveau" et "corrections" mais rien ne nous oblige à utiliser les autres tags. On peut mettre dans le changelog en français ce qui est fait afin qu'il soit exploitable directement en l'état. A chaque fin de release mensuelle on reliera et travaillera les points du changelog afin qu'ils soient compréhensibles pour un client.

En proposant un widget pour les versions sur le dashboard de Flow, il faudrait essayer de faire un lien, ou afficher uniquement les changements de la dernière version. Un lien doit pouvoir permettre de consulter le changelog entier. On pourra s'appuyer sur cette [librairie composer](https://github.com/erusev/parsedown) pour transformer le markdown en HTML.
<br><br>
**Exemple de changelog :**

# FLow

## [3.8] - Août 2020

### Nouveau
- fonctionnalité 1
- fonctionnalité 2

### Corrections
- bug 1
- bug 2
- bug 3