j.foucher
c20d4603a2
Bug rapporté : après avoir itéré des builds beta 1.5.4.30 / .31 / .32
(isBeta=true, 4-digit), publier 1.5.4 (isBeta=false, 3-digit) comme
release finale ne rendait PAS 1.5.4 la version "courante" côté launcher.
Deux cas d'échec :
1. Client canSeeBetas=true (opérateur/testeur) : les deux visibles,
1.5.4.32 restait en tête du tri (SemVer strict : 1.5.4 == 1.5.4.0
< 1.5.4.32).
2. Client canSeeBetas=false avec 1.5.4.32 déjà installé : l'install
locale n'est jamais filtrée par isBeta, donc restait en tête aussi.
Root cause : SemVer.CompareTo() traite le 4ᵉ digit comme un patch
post-release (documenté ainsi dans SemVer.cs pour supporter les itérations
de test 1.5.4.13 alignées sur leur release stable 1.5.4). Cette sémantique
casse quand le 4-digit est en fait un "pré-release" beta destiné à être
supplanté par la 3-digit finale.
Fix : nouveau helper VersionOrder.Compare(versionA, isBetaA, versionB,
isBetaB) qui ajoute une règle par-dessus SemVer :
Au MÊME préfixe 3-digit (X.Y.Z égaux) ET statut beta différent, la
version isBeta=false l'emporte, indépendamment du 4ᵉ digit.
Hors ce cas exact (préfixes 3-digit différents, ou même statut beta des
deux côtés) : SemVer strict, aucune régression sur les scénarios existants
(1.5.4.30 beta < 1.5.4.32 beta reste vrai, 1.5.4 < 1.5.5 reste vrai, etc.).
Application aux deux hotspots :
• UpdateChecker.CheckAsync — tri par VersionOrder au lieu de SemVer,
ET pour la comparaison isNewer, retrouve l'isBeta d'origine de l'install
locale via lookup dans manifest.Versions (si l'entrée existe encore).
• MainViewModel.RebuildList — tri combiné installé/remote via VersionOrder.
L'isBeta est lookupé dans le RAW remote (avant le filtre canSeeBetas),
sinon un client sans droits beta ayant installé une beta perdrait
l'info et retomberait sur SemVer strict.
Migration : aucune côté data. Les versions publiées comme beta restent
identifiées par leur flag isBeta ; le launcher les considère automatiquement
comme pré-release dès qu'une non-beta au même préfixe 3-digit apparaît
dans le manifest. Publish 1.5.4 (isBeta=false) → devient la version featured
même sur les postes ayant 1.5.4.32 installé.
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.