132 lines
6.4 KiB
Markdown
132 lines
6.4 KiB
Markdown
<!-- file: docs/rules/VERSION_WORKFLOW.md -->
|
|
<!-- version: 2 -->
|
|
|
|
# Versionnement, maturité et livraisons
|
|
|
|
## SemVer canonique
|
|
|
|
Le projet utilise SemVer et les labels de maturité normalisés suivants :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```text
|
|
deltas/X.Y.Z/<prerelease-or-rel>.md
|
|
```
|
|
|
|
Exemples :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```text
|
|
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.
|
|
|
|
## 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.
|