windows-build.yml:
- Remove the Qt5 build job (build-windows). Qt6 is now the sole
Windows track built in CI.
- publish-nightly-assets: only delete/replace .exe and .zip assets
tagged "qt6" on the nightly release. Assets without "qt6" in the
name (the last Qt5 build ever published) are left untouched and
stay downloadable indefinitely as a frozen legacy build.
- Release notes: drop the "Try Qt6 — soon the only track" notice,
add a line explaining the Qt5 (frozen) vs Qt6 (maintained) split.
windows-msi.yml:
- Matrix reduced to the single "qt6" entry (flavor string kept as
"qt6", not renamed, since it seeds the MSI ProductCode and a
rename would break upgrade detection for existing installs).
- Sign the Qt6 MSI via SignPath (previously Qt5-only). Guard is now
just the upstream-repo fork check; no per-flavor exclusion left.
- deploy-pages: also detect legacy (non-"qt6") release assets and
pass them to generate-page.py as LEGACY_INSTALLER_URL /
LEGACY_PORTABLE_URL / LEGACY_MSI_URL.
generate-page.py:
- Drop the old Qt5/Qt6 dual-track rendering; INSTALLER_URL /
PORTABLE_URL / MSI_URL now point at the Qt6 build directly.
- Add an optional "Windows — x86_64 — Qt5 (legacy, unmaintained)"
card, rendered only when LEGACY_* URLs are set, with a frozen/
no-longer-updated notice.
Before merging: manually trigger the current (pre-merge) "Windows
Build" + "Windows MSI" workflows once to publish an up-to-date,
signed Qt5 snapshot — that run becomes the frozen legacy reference,
since the Qt5 job won't exist to re-run afterwards.
No changes to QElectroTech.wxs (Qt5/Qt6-agnostic, only
QtPlatformArgs varies and is already handled at the CI level).
Version was static (X.Y.Z.0) across nightlies, so MajorUpgrade never triggered the automatic uninstall; the Windows Installer only compares Major.Minor.Build, ignoring the 4th field.
+ AllowSameVersionUpgrades="yes" to <MajorUpgrade>
windows-msi.yml — in the ‘Extract version’ step, calculate a unique GUID
based on the commit’s SHA, then pass -d ‘ProductCode=$productGuid’ to the WIX build
This ensures that each build will have a different ProductCode → MajorUpgrade will always be triggered
- Use SetProperty + WixQuietExec two-step pattern to pass runtime
INSTALLDIR to a deferred CustomAction (fixes WIX1077 and WIX0400)
- Add WixToolset.Util.wixext/7.0.0 extension (required for WixQuietExec)
- Fix condition syntax: collapse multi-line conditions to single line
- Add -ext WixToolset.Util.wixext to wix build command in windows-msi.yml
**`build-aux/windows/QElectroTech.wxs`**
- Desktop and Start Menu shortcuts now point directly to `bin\qelectrotech.exe` with all required arguments (`--common-elements-dir`, `--common-tbt-dir`, `--lang-dir`, `-style windowsvista`) — no `.bat` wrapper needed
- Added a deferred `CustomAction` that runs after `InstallFiles` and recursively sets all files in `elements\` to read-only using an inline PowerShell command
**`.github/workflows/windows-msi.yml`**
- Replaced the step that created `Lancer QET.bat` with a step that removes it from the artifact before the WiX build, so it is not embedded in the MSI
- The `.bat` file remains untouched in the ZIP portable build (managed by `windows-build.yml`)
- No console window flashing when launching QElectroTech from the MSI shortcuts
- The `elements\` directory is properly set to read-only after installation, as required
- Cleaner MSI package — no `.bat` file shipped to end users installing via MSI
↓
windows-build.yml
├── build-windows → generates an exe file + zip + portable artefact
└── deploy-pages → clears old files, uploads the exe file + zip to the ‘release nightly’ repository
↓ (workflow_run: completed + successful)
windows-msi.yml
├── uploads the portable artefact
├── builds the MSI with WiX v7
├── deletes the old .msi, uploads the MSI to the nightly version
└── generates and deploys GitHub Pages ← the 3 URLs are known here
The GitHub Pages page is no longer generated by windows-build.yml but by windows-msi.yml once the MSI is in the release
Removal of all envs: WIX_ACCEPT_EULA: true (does not work)
Addition of a dedicated ‘Accept WiX EULA’ step with wix eula accept wix7 before any other WiX command — this is the official CI/CD method, which writes a sentinel file to the user profile, thereby authorising all subsequent WiX commands in the same job.
Laurent Trinques