# 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.