57 lines
4.0 KiB
Markdown
57 lines
4.0 KiB
Markdown
<!-- file: ROADMAP.md -->
|
||
<!-- version: 21 -->
|
||
|
||
# Roadmap
|
||
|
||
## Légende
|
||
|
||
- `( )` — planned ;
|
||
- `(x)` — completed ;
|
||
- `(d)` — deferred ;
|
||
- `(c)` — cancelled.
|
||
|
||
Les marqueurs qualifient une ligne de scope. Une même version peut donc apparaître plusieurs fois si une partie est livrée, une partie reportée et une autre annulée.
|
||
|
||
## 0.1.0 — Fondation POC
|
||
|
||
- (x) `0.1.0` — squelette du workspace, règles, architecture, versions et assets.
|
||
- (x) `0.1.0` — moteur V1 POC, boucle de jeu, input abstrait et rendu SDL3 minimal.
|
||
- (x) `0.1.0` — Reflex et Snake jouables comme POC de réutilisation.
|
||
- (x) `0.1.0` — Desktop SDL3 natif, Android SDL3/Java/JNI et Tauri/WebView/WASM Reflex.
|
||
- (x) `0.1.0` — tracing commun, provenance runtime, packaging et validation multi-appareils.
|
||
|
||
Le détail historique des prereleases `0.1.0-*` reste dans `deltas/0.1.0/` et `history/0.1.0/`.
|
||
|
||
## 0.2.0 — Conception du framework modulaire
|
||
|
||
- (x) `0.2.0` — fixer la gouvernance documentaire, la nomenclature et le cycle de maturation des idées et décisions.
|
||
- (x) `0.2.0` — inventorier et réserver les capabilities déjà justifiées sans les implémenter prématurément.
|
||
- (x) `0.2.0` — définir les couches, les dépendances autorisées et la frontière entre kernel, capability, plateforme, provider, système de jeu et service.
|
||
- (x) `0.2.0` — établir la matrice plateformes et les archétypes de jeux utilisés pour challenger l'architecture.
|
||
- (x) `0.2.0` — retenir la composition Rust statique comme direction de référence.
|
||
- (d) `0.2.0` — figer un manifest produit/jeu et l'architecture physique définitive des crates → target TBD après observation des POC `0.3.x`.
|
||
- (x) `0.2.0` — définir la trajectoire d'implémentation progressive `0.3.x` POC puis `0.4.x` Uroburas.
|
||
- (x) `0.2.0` — consolider les études acceptées en architecture/règles durables, notamment ownership, réseau, Uroburas et POC, puis fermer les points encore candidats.
|
||
- (x) `0.2.0` — formaliser la stratégie réseau : Actix Web pour le Web/API, asset delivery auto-hébergé H2/H3, WebSocket baseline et WebTransport/QUIC candidat.
|
||
- (x) `0.2.0` — préparer une trajectoire `0.3.x` dédiée aux POC plateforme/réseau avec Snake comme jeu-sonde.
|
||
- (x) `0.2.0` — préparer la trajectoire `0.4.x` Uroburas Mode 1 et le prompt de session associé après gel de la conception.
|
||
|
||
## 0.3.0 — Baseline Snake + premier POC Web direct
|
||
|
||
- (x) `0.3.0` — nettoyer la baseline Snake sans introduire de logique Uroburas et maintenir le runner Desktop SDL3 fonctionnel.
|
||
- (x) `0.3.0` — produire une adaptation WASM dédiée à Snake sans déplacer le gameplay hors de `game-snake-poc`.
|
||
- (x) `0.3.0` — réaliser un POC navigateur direct Snake couvrant clavier, boutons directionnels tactiles, resize, lifecycle, logging, assets et provenance runtime.
|
||
- (x) `0.3.0` — utiliser uniquement Cargo, `wasm-bindgen` et Vite/npm pour le chemin de build Web ; aucun script Python ne pilote ce build.
|
||
- (x) `0.3.0` — documenter les duplications observées et conserver les adapters Web/WASM spécifiques tant qu’un second consommateur ne justifie pas une extraction commune.
|
||
|
||
## Série 0.3.x — trajectoire actuelle après 0.3.0
|
||
|
||
- ( ) `0.3.1` — second host Snake : Tauri Android, en réutilisant la baseline Web/WASM validée et en remplaçant toute orchestration Python du chemin touché.
|
||
- ( ) `0.3.2` — Tauri Desktop + Snake et factorisation WebView uniquement lorsque deux consommateurs réels justifient l'extraction.
|
||
- ( ) `0.3.3` — Android SDL natif multi-ABI avec Cargo/Gradle natifs, sans script Python de build.
|
||
- ( ) `0.3.4` — API de transport realtime + WebSocket/tokio-tungstenite baseline, sans serveur Uroburas Mode 3.
|
||
- ( ) `0.3.5` — POC WebTransport/QUIC sur le même protocole, avec comparaison mesurée et fallback WebSocket.
|
||
- ( ) `0.3.6` — consolidation des POC plateforme/réseau et préparation de la baseline `0.4.x`.
|
||
|
||
La numérotation `0.3.1+` reste révisable à partir des résultats réels ; les lignes ci-dessus décrivent le planning actuel, pas une obligation de créer des versions artificielles.
|