2.5 KiB
Historique 0.3.4-rc.1
Statut
0.3.4-rc.1 a été validée par l'utilisateur le 2026-09-21. La candidate gelée passe les audits, la compilation workspace, Clippy strict, les suites realtime ciblées, le smoke runtime et le contrôle inverse des dépendances sans défaut de publication.
Aucun rc.1.fix.N n'est requis. La candidate peut être promue mécaniquement vers la stable 0.3.4.
Gates statiques et compilation
La sortie utilisateur confirme :
General Rust rule audit: clean
Rust export completeness audit: 0 candidate(s)
games.sasedev workspace audit: clean
Markdown table audit: clean (5 table(s), 277 file(s))
Distribution layout audit: clean (50 required path(s), 8 forbidden path(s) absent)
cargo fmt --all: clean
cargo fmt --all -- --check: clean
cargo check --workspace: clean
cargo clippy --workspace --all-targets --all-features -- -D warnings: clean
Le workspace compilé porte 0.3.4-rc.1, y compris les deux crates realtime et le launcher de smoke.
Tests realtime
Le contrat transport-neutral passe :
cargo test -p game-realtime-transport-lib --all-targets --all-features
7 passed; 0 failed
Le backend WebSocket passe ses trois ensembles de tests :
unit tests: 5 passed; 0 failed
loopback: 1 passed; 0 failed
robustness: 5 passed; 0 failed
La RC valide donc 18 tests realtime ciblés, 0 échec. Le full workspace de 53 tests avait déjà été validé en beta.1 et n'a pas été répété puisque la RC n'a modifié aucun code Rust ni dépendance fonctionnelle.
Smoke runtime
La commande :
cargo run -p game-realtime-websocket-smoke
passe hors harness #[test] et affiche :
game-realtime-websocket-smoke: PASS
Le log fourni montre un bind loopback éphémère, l'accept serveur, la connexion cliente, l'échange prévu et la fermeture propre. Le port observé 46581 est propre à cette exécution ; le smoke continue de binder 127.0.0.1:0.
Frontière de dépendances
L'arbre inverse :
cargo tree -i game-realtime-websocket-lib --workspace --edges normal
ne contient qu'un consommateur workspace :
game-realtime-websocket-smoke
Aucune crate moteur ou gameplay ne dépend donc du backend WebSocket.
Conclusion RC
Le comportement realtime et sa documentation de publication sont gelés et validés. La stable peut se limiter aux changements mécaniques de version, changelog, roadmap, clôture du plan, historique RC et delta final.