j.foucher
49a3b855af
Changement majeur du modèle de channels en réponse au feedback :
« c'est trop compliqué. Il faudrait juste pouvoir tout laisser dans
builds, et taguer une version dans un canal ou un autre voir plusieurs
canaux. ». Le précédent design (1 fichier manifest par channel +
sous-dossier builds/{channel}/) imposait une duplication de structure
et empêchait une version d'être visible sur plusieurs channels à la fois.
NOUVEAU MODÈLE :
- 1 seul fichier manifest/versions.json
- 1 seul dossier builds/ flat (les ZIPs ont des noms libres pour éviter
les collisions homonymes — proserve-1.5.3.zip, proserve-1.5.3-police.zip…)
- Chaque entry de version a un champ `channels: ["default", "police"]`
qui dit qui peut la voir
- Sémantique additive : un client sur channel "police" voit les versions
taggées "default" + celles taggées "police". "default" = public.
- Une version peut être taggée sur plusieurs channels en une fois.
NOUVEAU REGISTRE channels.json :
Le registre des channels (avec name + label + description) vit dans
manifest/channels.json. Le channel "default" est implicite et ne peut
pas être supprimé. Nouvelle page admin Channels (CRUD) pour gérer la
liste, avec garde-fou anti-suppression : compte les versions taggées
et les licenses attribuées avant d'autoriser la suppression.
SERVEUR :
- api/routes/Manifest.php : reçoit ?channel=X depuis la license,
filtre versions où channels[] contient X ou "default", re-signe avec
la clé privée Ed25519 à la volée. Coût ~1ms par requête.
- admin/versions.php : refactor — plus de session "channel actif", plus
de switcher en haut, plus de prefix builds/{channel}/. Add form a
des checkboxes channels[]. Nouveau bouton "Channels" par-row pour
retager.
- admin/licenses.php : dropdown channel alimenté depuis channels.json
au lieu de scanner les fichiers manifest.
- tools/SignManifest.php : revert du constructeur channel-aware,
toujours sur versions.json + builds/ flat.
CLIENT :
- VersionManifest.Channels (List<string>) ajouté pour debug, mais le
filtrage est server-side donc le client n'a rien à faire de ce champ
côté UX.
- L'envoi du ?channel=X depuis la license signée fonctionne déjà
depuis v0.26.0, pas de changement nécessaire.
MIGRATION :
Les fichiers manifest/versions-{X}.json créés en v0.26.0 deviennent
inutiles. Si tu en avais (test "police" par exemple), copie les
versions concernées dans versions.json et tague-les avec les bons
channels via la nouvelle UI.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PS_Launcher
Launcher Windows pour l'application UE5 PROSERVE : gère plusieurs versions cohabitantes, téléchargement et installation de nouvelles versions depuis un serveur, validation de license, release notes.
Composants
src/— Solution C# / .NET 8 / WPF (Visual Studio 2022 + SDK .NET 8 requis)PSLauncher.App: UI WPF (style Epic Games Launcher)PSLauncher.Core: services (Manifest, Download, Install, Process…)PSLauncher.Models: DTOs partagés
server/— Code serveur PHP 8 (à déployer souswww/PS_Launcher/sur OVH mutualisé)
Démarrage rapide (dev)
dotnet build PS_Launcher.sln
dotnet run --project src/PSLauncher.App
Pour produire un binaire autonome distribuable (un seul .exe ~70 Mo) :
dotnet publish src/PSLauncher.App -c Release
# Sortie : src/PSLauncher.App/bin/Release/net8.0-windows/win-x64/publish/PSLauncher.exe
Configuration locale
Le launcher écrit sa config dans %LocalAppData%\PSLauncher\config.json au premier lancement.
Édite serverBaseUrl pour pointer vers ton serveur :
{
"serverBaseUrl": "https://ton-domaine.com/PS_Launcher/api",
"installRoot": "C:\\ASTERION\\GIT\\PS_Launcher\\ASTERION_VR"
}
État (roadmap)
- ✅ v0.1 — Scan + lancement de versions installées
- ✅ v0.2 — Manifest distant, download ZIP, install cohabitante, release notes Markdown
- ⏳ v0.3 — Reprise (HTTP Range), retry Polly, state.json
- ⏳ v0.4 — License (MySQL + Ed25519 + DPAPI)
- ⏳ v0.5 — Settings, suppression manuelle versions, toasts
- ⏳ v1.0 — Auto-update launcher, MSI installer
Voir le plan détaillé pour la roadmap complète.
Licence / interne
Repo interne ASTERION. Ne pas distribuer.