112 lines
2.9 KiB
Markdown
112 lines
2.9 KiB
Markdown
# 36. SemVer et politique de releases
|
|
|
|
## 36.1 SemVer — V1 REQUIS — FIGÉ POUR L'ÉCOSYSTÈME
|
|
|
|
Les packages Saselang utilisent **Semantic Versioning 2.0.0 strict**.
|
|
|
|
```text
|
|
MAJOR.MINOR.PATCH
|
|
```
|
|
|
|
Les versions publiées, les contraintes de dépendances, le resolver et le lockfile doivent respecter SemVer 2.0.0. Saselang ne définit pas un ordre de versions concurrent à SemVer.
|
|
|
|
## 36.2 Discipline de compatibilité officielle — V1 REQUIS — FIGÉ EN PRINCIPE
|
|
|
|
Pour Core, SDK et packages officiels Saselang :
|
|
|
|
```text
|
|
MAJOR -> rupture de compatibilité publique
|
|
MINOR -> ajout rétrocompatible
|
|
PATCH -> correction rétrocompatible
|
|
```
|
|
|
|
Avant `1.0.0`, l'écosystème officiel peut imposer des règles plus strictes que le minimum SemVer afin de rendre l'évolution de Core/SDK plus prévisible.
|
|
|
|
Cette discipline est une norme de développement/publication de l'écosystème Saselang ; elle n'est pas une règle syntaxique du langage.
|
|
|
|
## 36.3 Stades officiels de prerelease — ÉCOSYSTÈME SASLANG — FIGÉ EN PRINCIPE
|
|
|
|
L'écosystème officiel utilise l'ordre conceptuel :
|
|
|
|
```text
|
|
pre -> alpha -> beta -> rc -> stable
|
|
```
|
|
|
|
Signification :
|
|
|
|
```text
|
|
pre développement/intégration active ; fonctionnalités incomplètes possibles
|
|
alpha ensemble cohérent et testable ; API encore susceptible d'évoluer
|
|
beta fonctionnalités prévues essentiellement complètes ; stabilisation
|
|
rc candidat à la release ; changements limités aux corrections nécessaires
|
|
stable aucun identifiant de prerelease
|
|
```
|
|
|
|
Pour que cet ordre soit également l'ordre de précédence **SemVer standard**, la forme canonique recommandée pour les packages officiels est :
|
|
|
|
```text
|
|
X.Y.Z-0.pre.N
|
|
X.Y.Z-1.alpha.N
|
|
X.Y.Z-2.beta.N
|
|
X.Y.Z-3.rc.N
|
|
X.Y.Z
|
|
```
|
|
|
|
Exemple :
|
|
|
|
```text
|
|
1.4.0-0.pre.3
|
|
1.4.0-1.alpha.1
|
|
1.4.0-2.beta.2
|
|
1.4.0-3.rc.1
|
|
1.4.0
|
|
```
|
|
|
|
Les nombres de prerelease SemVer ne comportent pas de zéros initiaux.
|
|
|
|
## 36.4 Fix de prerelease — ÉCOSYSTÈME SASLANG — FIGÉ EN PRINCIPE
|
|
|
|
Un correctif portant sur une `pre`, `alpha`, `beta` ou `rc` peut utiliser un composant `fix` supplémentaire :
|
|
|
|
```text
|
|
X.Y.Z-0.pre.N.fix.M
|
|
X.Y.Z-1.alpha.N.fix.M
|
|
X.Y.Z-2.beta.N.fix.M
|
|
X.Y.Z-3.rc.N.fix.M
|
|
```
|
|
|
|
Exemple :
|
|
|
|
```text
|
|
1.4.0-3.rc.2
|
|
1.4.0-3.rc.2.fix.1
|
|
1.4.0-3.rc.3
|
|
```
|
|
|
|
Une release stable n'utilise jamais `fix`. Une correction de :
|
|
|
|
```text
|
|
1.4.0
|
|
```
|
|
|
|
produit une nouvelle version PATCH, par exemple :
|
|
|
|
```text
|
|
1.4.1
|
|
```
|
|
|
|
La notation conceptuelle `-fix.NNN` n'est donc pas utilisée telle quelle si elle violerait ou perturberait les règles de SemVer strict ; `fix.M` fait partie de l'identifiant de prerelease et `M` n'a pas de zéros initiaux.
|
|
|
|
## 36.5 Build/documentation metadata — ÉCOSYSTÈME SASLANG — FIGÉ
|
|
|
|
`build` et `doc` ne sont pas des stades de prerelease.
|
|
|
|
SemVer fournit les métadonnées de build :
|
|
|
|
```text
|
|
X.Y.Z+build.N
|
|
X.Y.Z+doc.N
|
|
```
|
|
|
|
Elles ne modifient pas la précédence de version et ne constituent pas une nouvelle release de compatibilité.
|