Sasedev/games
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.2.0-0-pre.1-fix.1

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-18 00:58:14 +02:00
parent de63a8c57b
commit df4a06fac3
23 changed files with 317 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
docs/rules/VERSION_WORKFLOW.md
View File

@@ -88,3 +88,37 @@ Les gates techniques sont proportionnelles aux fichiers touchés :
- 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.