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 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 — 0-pre.1 est obligatoirement la tranche de cadrage de la version : audit de la base, brainstorming/recherche de requirements, sizing, planification, dépendances, validations attendues et découpage prévisionnel.
• VER-PHASE-003 — 0-pre.1 peut aussi contenir une première implémentation strictement bornée si le cadrage montre qu'elle tient naturellement dans la même tranche, mais le cadrage ne doit jamais être sauté.
• VER-PHASE-004 — Une version doit être dimensionnée pour que l'ensemble de son développement puisse être terminé dans une seule session de travail. Si ce n'est pas réaliste, son objectif est découpé en plusieurs versions/sessions avant le développement lourd.
• VER-PHASE-005 — Le plan établi en 0-pre.1 est vivant : il peut regrouper, scinder, reporter ou reclasser des tranches lorsque l'information réelle le justifie, sans réécrire les deltas déjà livrés.
• VER-PHASE-006 — Une tranche pre.N, alpha.N, beta.N, rc.N ou leur fix vise normalement un delta réalisable en environ 15 à 30 minutes. Une tranche sensiblement plus lourde est découpée avant exécution ; une tranche trop petite peut être regroupée avec une tranche adjacente cohérente.
• VER-PHASE-007 — Le découpage privilégie des unités fonctionnelles complètes et validables, pas des coupures arbitraires au milieu d'une fonctionnalité.
• VER-PHASE-008 — Chaque tranche ferme son propre scope, produit son delta et ses validations proportionnelles avant l'ouverture de la tranche suivante.
• VER-PHASE-009 — Alpha, beta et RC sont utilisées proportionnellement au risque et à la maturité ; elles ne sont pas créées uniquement pour satisfaire une séquence cérémonielle.
• VER-PHASE-010 — La dernière tranche de développement avant la candidate de publication est réservée à la consolidation : validations finales, documentation durable, CHANGELOG.md, ROADMAP.md, historique applicable et préparation du prompt de la version/session suivante.
• VER-PHASE-011 — La release stable est autant que possible mécanique : elle ne doit pas introduire une nouvelle fonctionnalité, une nouvelle décision architecturale ou un nouveau scope non validé dans une candidate précédente.

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.

Corrections des deltas déjà livrés

• VER-DELTA-001 — Un delta livré n'est jamais enrichi après coup.
• VER-DELTA-002 — Une correction purement orthographique, typographique, d'alignement ou de forme sans changement de sens peut être appliquée au fichier delta existant si son en-tête version est incrémenté.
• VER-DELTA-003 — Une correction qui change le sens, le scope, les validations, les suppressions ou les décisions produit un nouveau .fix.N.
• VER-DELTA-004 — Les manifests *.delete.txt sont toujours décrits dans le delta Markdown qui les introduit.