Reverts the switch to calendar versioning, before it produced a release here.
release-please has no CalVer strategy, so the switch reset the version series by hand and pinned always-bump-patch. What that analysis missed is what release-please does to the changelog when the series it is walking no longer connects to the tag history: on MSIME-Apple it rewrote the whole file into a single 158-line 2026.9.1 entry that listed every feature since the first pull request as though it had just shipped. MSIME-Linux got a 64-line one. This repository had not released yet, so there is no changelog damage to undo and reverting now costs nothing.
Restores the 0.0.17 baseline across version.txt, .release-please-manifest.json and the version resource, drops always-bump-patch from the release-please config, and removes the monthly rollover workflow. The next release goes back to the previous series.
The three version lines the switch was meant to unify stay unaligned. That problem is real but wants a mechanism that does not fight release-please.
The three platform frontends of one product carried three unrelated version lines: Windows 0.0.17, Linux 0.6.0 and Apple 0.41.0, all built on the same engine. A user reporting a problem with "0.41" said nothing about which platform they were on, and the main product carried the lowest number of the three.
All three now start from 2026.9.0. Every platform moves up, so no update mechanism sees a downgrade: Sparkle compares components numerically, the Windows update manifest accepts any dot-separated digits, and 2026.9.0 is a valid and higher version for both dpkg and rpm.
release-please has no CalVer strategy — its only options are default, always-bump-patch, always-bump-minor, always-bump-major, service-pack and prerelease — so always-bump-patch is pinned to walk the last component within a month, and .github/workflows/calver-rollover.yml moves the year and the month. Without that workflow the date in the version would freeze and keeping it truthful would become a manual edit somebody has to remember, which is the failure this project has already been bitten by elsewhere.
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.
fanlusky