2.9 KiB
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.
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 :
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 :
pre -> alpha -> beta -> rc -> stable
Signification :
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 :
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 :
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 :
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 :
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 :
1.4.0
produit une nouvelle version PATCH, par exemple :
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 :
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é.