The Server job failed linking MetasequoiaImeSettings:
LINK : fatal error LNK1181: cannot open input file
'D:\a\MSIME-Windows\MSIME-Windows\build\vcpkg_installed\x64-windows\lib\WebView2Loader.dll.lib'
MSIME-Server's CMakeLists.txt hardcodes ${CMAKE_SOURCE_DIR}/build/vcpkg_installed at lines 257, 369 and 412, for the WebView2 loader and two include paths, so the binary directory has to be literally named build. Its own CI uses -B build and never hits this; this workflow used -B build-release to match the layout Prepare-PackageFiles.ps1 reads from.
The directory name here does not actually need to match, because the packaging job downloads the Server artifact into MetasequoiaImeServer/build-release/bin/Release itself. Building in build/ keeps this in step with MSIME-Server's own green CI and leaves the staged layout unchanged.
The release build failed at "Verify the stamped version" on both architectures. Stamping worked, the log shows "Stamped 0.0.10.0 into src\IME\MetasequoiaIME.rc (4 fields)", but reading the DLL back gave an empty string.
The VERSIONINFO block in src/IME/MetasequoiaIME.rc is named IDR_VERSION2, which is not defined in resource.h or anywhere else, rather than the VS_VERSION_INFO that GetFileVersionInfo looks for. So the DLL has never carried a version Windows can read, and the check asserted something the binary could never satisfy.
Stamping now runs apply_version.py followed by --check, which verifies the resource actually matches version.txt. The step on the built artifact is reduced to confirming the DLL the installer collects exists.
Making the version readable would mean renaming the resource to VS_VERSION_INFO, which changes what the shipped DLL exposes, so it is left alone here.
The Windows installer has been produced by hand: build the TSF DLLs and the Server locally, build the settings page, copy dictionaries out of a developer checkout, then run the msime-installer scripts against a self-signed certificate. This automates that end to end, keeping the same artifact name the releases have always carried, MetasequoiaIME_Setup_v<version>.exe.
The workflow follows the shape of MSIME-Apple's release.yml. release-please owns version.txt and opens a release PR; merging it creates a draft release, which the publish path then builds and fills in. A manual dispatch can rebuild an existing draft tag, and validates that the tag matches version.txt at an immutable commit SHA before anything is built.
Four jobs feed the packaging job: the TSF DLLs for x64 and Win32, the Server Release build, and the settings page. msime-installer needs no changes because the packaging job stages each checkout under the historical directory name its scripts already address, so Prepare-PackageFiles.ps1 and Compile-Installer.ps1 run unmodified. windows-2025 ships Inno Setup 6.7.1, above the 6.6 the scripts require.
Dictionaries are not rebuilt here. They are downloaded from a dict-* release of metasequoiaime/MSIME-Dict and checked against its SHA256SUMS.txt, with the Mozc IPAdic / ICOT / Okinawa notice placed where Prepare-PackageFiles.ps1 expects so it reaches the installed product.
Signing follows the pattern MSIME-Apple uses: sign when the certificate secrets are configured, otherwise publish with an -unsigned suffix and say in the release notes that uiAccess will not take effect. Sign-PackageBinaries-Local.ps1 mints a self-signed certificate for local testing and is never invoked here.
release-please cannot drive the VERSIONINFO block in the resource script, which spells the version both as a comma quad and as a dotted string, so scripts/apply_version.py stamps it from version.txt before the release build configures CMake. It also has a --check mode. The committed resource moves off the stale 1.0.0.1 placeholder to the current 0.0.9.
The manifest starts at 0.0.9 rather than the four-part 0.0.9.2 that semver cannot express, so the next release will be 0.0.10, which still sorts after every existing tag.
Evan Hu