0.3.1-2-beta.1

This commit is contained in:
2026-09-21 08:11:36 +02:00
parent d8e7951a04
commit e5a4d7fe44
13 changed files with 551 additions and 33 deletions

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-V0_3_1_TAURI_ANDROID_SNAKE_PLAN.md -->
<!-- version: 9 -->
<!-- version: 10 -->
# Plan v0.3.1 — second host Snake Tauri Android
@@ -139,30 +139,28 @@ Si aucune extraction n'est justifiée, cette tranche est omise.
### `2-beta.1` — validation large et packaging Android
Tranche ouverte après validation de `0-pre.4.fix.1`. Aucun `0-pre.5` n'est justifié : aucune extraction Web/Tauri ne conserve assez de valeur maintenant que le host Android Tauri est explicitement un POC de référence.
Tranche validée le 2026-09-21. Aucun `0-pre.5` n'était justifié : aucune extraction Web/Tauri ne conserve assez de valeur maintenant que le host Android Tauri est explicitement un POC de référence.
Prévoir :
Résultats acquis :
- audits statiques applicables ;
- `cargo fmt --all -- --check` ;
- `cargo check --workspace` ;
- Clippy workspace strict ;
- suite workspace complète à ce jalon planifié ;
- build WASM release et bindings ;
- `cargo tauri android build` ;
- APK de validation du POC de référence ;
- AAB uniquement si une valeur de validation supplémentaire est démontrée, pas par automatisme de distribution ;
- install/smoke AVD ;
- install/smoke appareil ARM64 réel si disponible ;
- vérification que les outputs restent hors racine du dépôt lorsqu'ils sont configurables par le projet.
- audits statiques, `cargo fmt`, `cargo check --workspace` et Clippy workspace strict propres ;
- suite `cargo test --workspace --all-targets --all-features` propre avec 35 tests réussis et aucun échec ;
- hook Tauri `beforeBuildCommand` : WASM release, `wasm-bindgen`, TypeScript/Vite et copie des assets réussis ;
- APK Debug universal généré avec `aarch64-linux-android` et `x86_64-linux-android` ;
- installation et lancement réussis sur Galaxy S9+ ARM64 réel puis AVD API 36 x86_64 ;
- aucun serveur Vite, port `1436` ou tunnel ADB requis pour le package autonome.
### `2-beta.2` — consolidation documentaire conditionnelle
Le contrôle `unzip` explicite des deux entrées ABI n'a pas été fourni dans la sortie utilisateur ; la RC le conserve donc comme contrôle mécanique, même si l'installation/lancement du même APK sur ARM64 et x86_64 exerce déjà les deux architectures en pratique.
Réserver seulement si les validations beta demandent une consolidation substantielle de `README.md`, `USAGE.md`, architecture, matrice de validation ou plan. Ne pas créer cette tranche par cérémonial.
### `2-beta.2` — omise
Aucune consolidation beta supplémentaire ne justifie une tranche autonome. Les documents durables nécessaires sont consolidés directement à l'ouverture de la RC.
### `3-rc.1` — candidate gelée
Gel fonctionnel, reproductibilité, packaging Android RC et validation finale selon les règles RC applicables. Aucun nouveau framework ni nouveau host.
Tranche ouverte après validation de `2-beta.1`. Gel fonctionnel strict, synchronisation des versions RC, `CHANGELOG.md`, historique beta, matrice RC spécifique `0.3.1` et préparation du prompt de la prochaine version active. Aucun nouveau framework, host, gameplay ou comportement.
La gate RC revalide le workspace complet et l'APK autonome universal sur x86_64 + ARM64. Aucun AAB Tauri n'est demandé : l'AAB est réservé à la future voie Android SDL3 native où il constitue un vrai artefact de distribution.
### `0.3.1` — release stable
@@ -206,4 +204,4 @@ La version peut entrer en RC lorsque :
## Version suivante
`0.3.2` devient une évaluation conditionnelle de Tauri Desktop + Snake. Elle nest ouverte que si la WebView Desktop apporte un bénéfice explicite, notamment une piste de monétisation publicitaire viable ; la factorisation WebView reste interdite sans deux consommateurs réellement retenus.
`0.3.2` reste différée : aucune voie de monétisation Desktop/WebView suffisamment démontrée ne justifie son ouverture. La prochaine version active prévue est `0.3.3`, consacrée à Android SDL3 natif multi-ABI. Son `0-pre.1` devra notamment cadrer un AAB de distribution, distinguer compatibilité ABI et compatibilité de version Android, puis déterminer expérimentalement le `minSdk` réellement soutenable avant de promettre le support danciens appareils.