games/docs/rules/VERSION_WORKFLOW.md

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

Travail en RC

• VER-RC-001 — Une RC est fonctionnellement gelée. Les nouvelles fonctionnalités, nouvelles capabilities, refactors architecturaux non indispensables et changements volontaires de comportement sont interdits.
• VER-RC-002 — Les modifications de code restent autorisées en RC lorsqu'elles corrigent un bug, un test erroné, un défaut de packaging, un problème de sécurité, une incompatibilité de release ou un défaut strictement nécessaire à la publication.
• VER-RC-003 — Un correctif conforme à VER-RC-002 produit 3-rc.N.fix.M et n'impose pas un retour automatique en beta.
• VER-RC-004 — Si le périmètre fonctionnel est rouvert pendant une RC, la candidate est abandonnée et le développement revient à une phase adaptée, normalement beta, avant une nouvelle RC.

Prompt de la version suivante

• VER-PROMPT-001 — Le prompt de démarrage de la version suivante n'est pas créé à un numéro arbitraire de RC.
• VER-PROMPT-002 — Sa génération devient recommandée après validation de la première RC dont le périmètre est effectivement gelé.
• VER-PROMPT-003 — Le prompt peut être complété pendant les fixes RC ou la release stable, mais ne doit pas contenir de résultats futurs présentés comme déjà validés.

Phases de développement

Une version de code suit conceptuellement :

PLAN → IMPLEMENT → INTEGRATE → VALIDATE → CANDIDATE → RELEASE

• VER-PHASE-001 — Ces phases structurent le travail mais n'imposent pas une prerelease distincte pour chacune.
• VER-PHASE-002 — Une petite version peut combiner planification et première implémentation dans 0-pre.1.
• VER-PHASE-003 — Une version lourde peut réserver 0-pre.1 à la planification/décomposition et utiliser plusieurs pre.N pour l'implémentation avant alpha/beta.
• VER-PHASE-004 — La phase de planification doit identifier le scope, les dépendances, les validations attendues et le découpage de livraison sans dupliquer le contenu normatif de ROADMAP, RULES ou de la matrice de commandes.
• VER-PHASE-005 — La phase de validation vérifie l'état effectivement implémenté ; elle ne réécrit pas rétroactivement le plan initial.

Versions Tauri/frontend

• VER-TAURI-001 — Pour une app Tauri Rust du workspace, la version produit canonique est la version Cargo.
• VER-TAURI-002 — tauri.conf.json omet version lorsque Tauri peut hériter de la version Cargo.toml.
• VER-TAURI-003 — La version de package.json décrit le package frontend local et n'est pas synchronisée à chaque pre.N ou .fix.N.
• VER-TAURI-004 — Tant que le frontend n'est pas publié comme package npm, sa version est mise à jour uniquement aux jalons significatifs retenus par le projet, au minimum lorsque cela est nécessaire pour alpha, beta, RC ou stable.