Add Release protocol

RELEASING.md

@@ -0,0 +1,64 @@
+# Versioning
+
+Le projet utilise [la méthode sémantique de version](https://semver.org/lang/fr/).
+
+> Étant donné un numéro de version MAJEUR.MINEUR.CORRECTIF, il faut incrémenter :
+>
+> 1. le numéro de version MAJEUR quand il y a des changements non rétrocompatibles,
+> 1. le numéro de version MINEUR quand il y a des ajouts de fonctionnalités rétrocompatibles,
+> 1. le numéro de version de CORRECTIF quand il y a des corrections d’anomalies rétrocompatibles.
+>
+> Des libellés supplémentaires peuvent être ajoutés pour les versions de pré-livraison et pour des méta-données de construction sous forme d’extension du format MAJEURE.MINEURE.CORRECTIF.
+
+Ainsi nous utilerons le format `MAJOR.MINOR.PATCH` pour nos versions.
+Le libellé supplémentaire sera le suffixe `-rcX` pour les version en pré-release (release candidate).
+
+Examples de noms de versions valides: `1.0.0`, `1.0.1`, `1.1.0`, `2.0.0`, `2.0-rc1`, `2.0-rc2` .
+
+Un example réel: https://kernel.org/
+
+
+# `package.json`
+
+La version courante complète est indiquée dans le `package.json`.
+
+En utilisant `npm`, on peut facilement mettre à jour ce nombre :
+
+```
+npm version major
+npm version minor
+npm version patch
+```
+
+
+# Git
+
+Chaque version est tag par git sur la branche master.
+
+Pour tag :
+
+```
+git tag -a v1.0.0 -m "Release v1.0.0"
+```
+
+Pour pousser les modifications puis les tags :
+
+```
+git push origin master
+git push origin master --tags
+```
+
+Ou pour faire les deux en même temps
+
+```
+git push origin master --follow-tags
+```
+
+Si vous êtes sur une branche autre que `master`, veuillez **NE PAS TAG**. Si vous voulez versionner la branche, créez une branche avec la version dans le nom : `v1.1-rc1`.
+
+
+# Azure Pipeline
+
+Les tests d'Azure Pipeline sont lancés à condition que le nom de la branche soit `master` ou soit préfixée par la lettre `v`
+
+Exemples: `master`, `v1.0.2`, `v1.0-rc1`, `v1.0.1-mafeature` etc.