1.9 KiB
Versioning
Le projet utilise la méthode sémantique de version.
Étant donné un numéro de version MAJEUR.MINEUR.CORRECTIF, il faut incrémenter :
- le numéro de version MAJEUR quand il y a des changements non rétrocompatibles,
- le numéro de version MINEUR quand il y a des ajouts de fonctionnalités rétrocompatibles,
- 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.