Versionnement, maturité et livraisons

SemVer canonique

Le projet utilise SemVer et les labels de maturité normalisés suivants :

X.Y.Z-0-pre.N
X.Y.Z-0-pre.N.fix.M
X.Y.Z-1-alpha.N
X.Y.Z-1-alpha.N.fix.M
X.Y.Z-2-beta.N
X.Y.Z-2-beta.N.fix.M
X.Y.Z-3-rc.N
X.Y.Z-3-rc.N.fix.M
X.Y.Z

N et M sont des entiers positifs sans zéro initial.

Sens des niveaux

0-pre.N : construction initiale, architecture et fonctionnalités encore très mouvantes ;
1-alpha.N : périmètre fonctionnel principal établi mais encore incomplet ou instable ;
2-beta.N : fonctionnalités attendues largement présentes, priorité à la stabilisation et aux tests ;
3-rc.N : candidat de publication, aucune évolution non indispensable ;
X.Y.Z : version stable.

Correctifs

Un suffixe .fix.M corrige la prerelease immédiatement précédente sans changer son objectif fonctionnel. Exemple :

0.1.0-0-pre.4
0.1.0-0-pre.4.fix.1
0.1.0-0-pre.4.fix.2
0.1.0-0-pre.5

Après une version stable, un correctif produit normalement un nouveau patch SemVer, par exemple 0.1.1, et non 0.1.0.fix.1.

Version workspace et versions autonomes

Les crates héritent par défaut de workspace.package.version. Une crate mature peut adopter sa propre version lorsque son contrat, sa compatibilité ou sa distribution justifie un cycle autonome. Cette décision est documentée dans le delta qui l'introduit.

Livraisons

La livraison normale est une archive delta. Le nom canonique est :

games-sasedev-<semver>-delta.zip

Le delta contient uniquement les fichiers ajoutés ou modifiés relativement à la base déclarée, plus le document de delta correspondant. La toute première livraison constitue nécessairement une baseline et son delta contient l'ensemble des fichiers initiaux.

Deltas

Les documents sont rangés sous :

deltas/X.Y.Z/<prerelease-or-rel>.md

Exemples :

deltas/0.1.0/0-pre.1.md
deltas/0.1.0/0-pre.1.fix.1.md
deltas/0.1.0/1-alpha.1.md
deltas/0.1.0/3-rc.2.md
deltas/0.1.0/rel.md

Versions principalement documentaires

Une version de conception suit le même SemVer que les autres versions et peut utiliser plusieurs 0-pre.N pour permettre une revue humaine progressive.

Les audits Markdown et de règles valident la cohérence mécanique mais ne valent jamais acceptation du fond documentaire. Une prerelease documentaire reste candidate jusqu'à revue explicite de son contenu.

Les gates techniques sont proportionnelles aux fichiers touchés :

un delta uniquement documentaire exécute les audits documentaires applicables ;
une modification Rust déclenche les gates Rust prévues par les règles ;
une modification Android/Gradle déclenche les gates Android concernées ;
une modification Tauri/frontend/build déclenche les gates correspondantes.

La promotion rc puis stable d'une version de conception exige une validation humaine explicite du contenu consolidé.

3.0 KiB Raw Blame History