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