scripts/dev-build-version.py turns version.txt plus the head commit into
0.7.1-dev.20261019.<hash>: the -dev display string for installer names and
the native settings page, and a YYMMDD stamp for the fourth VERSIONINFO field.
apply_version.py accepts an optional fourth quad field to carry that stamp;
releases leave it at 0, so their behaviour is unchanged. The settings page's
version parser strips the -dev suffix and compares numbers, which is what
keeps the update check quiet on dev installs -- no opt-out flag needed.
Adds a manual test_signing dispatch that uses GitHub-hosted runners, test-signing policy, signer verification, and run-summary request links without publishing a release.
* fix(server): drop part-of-speech labels from Ctrl+Enter translation senses
The machine-translated Chinese-to-English glosses prefix each sense with a
label ("n. silver medal", "proper n. Wanshan District"). The candidate
window keeps showing the whole gloss, but splitting it for Ctrl+Enter now
strips the label so it never reaches the committed text.
* feat(installer): build cn-en translations into the local dictionary
build-dictionary.py gains a cn-en-translations stage that loads
sources/cn-en/machine-translations.txt from msime-dictionary into
zh_en_glosses verbatim, keeping every sense instead of the two the ECDICT
derivation keeps. It runs after english-glosses and before
custom-translations, so it overrides ECDICT and custom/translations.txt
still overrides it.
Local full test packages now always build the dictionary from the sibling
msime-dictionary checkout instead of downloading the product-lock release:
Invoke-LocalTest.ps1 and prepare-package-inputs.ps1 call
build-dictionary.py --if-stale, which skips only when out/ was built from
the current clean source commit by the current builder. CI and releases
still take the dictionary from product-lock.json.
* ci(release): run the SignPath path on GitHub-hosted runners
SignPath's open-source plan accepts a signing request only when every job leading up to it ran on a GitHub-hosted runner, and tsf, server and package all ran on the self-hosted release machine. With WINDOWS_SIGNING_PROVIDER=signpath they now run on windows-2025, restoring vcpkg binaries and (for the Server) sccache the way ci.yml does; the certificate path keeps the self-hosted runner unchanged.
The org secret holding the SignPath API token is SIGNPATH_TOKEN, so the workflow and detect-release-signing.ps1 read that name instead of SIGNPATH_API_TOKEN.
AGENTS.md lists what SignPath needs configured, and the code signing policy records the accepted application and the hosted-runner rule.
* fix(ci): let the SignPath action read the run's artifacts
* fix(installer): drop authenticode-sign attributes SignPath Foundation rejects
* fix(ci): fail the hosted SignPath release before signatures are spent
- Probe ISCC with WizardStyle=modern dynamic and run that probe at the start of the hosted package job, so an image ISCC older than 6.6 fails before the payload signing request instead of after it.
- Verify the TSF vcpkg root before installing into it or saving its archives under the -complete key.
- Check the Server job's C:\vcpkg override against the vcpkg the hosted image puts on PATH.
- Code signing policy: drop the stale "once approved" wording and state that the hosted-runner rule applies to SignPath-signed releases.
* docs: list only the configured SignPath approver
---------
Co-authored-by: fanlusky <1730976608@qq.com>
The release job can now sign through SignPath instead of the certificate in the repository secrets. It only does so when the WINDOWS_SIGNING_PROVIDER repository variable is set to signpath, which nothing sets yet, so every release keeps taking the existing certificate path until a maintainer switches it.
On the SignPath path, scripts/ci/signpath-files.ps1 stages only the project's own binaries (the seven Server executables and both TSF DLLs) as the signing request's artifact, because SignPath Foundation does not allow signing the third-party DLLs vcpkg builds for the Server. The signed files are checked for a valid Authenticode signature before they replace the originals, and staging fails if a MetasequoiaIme* binary is missing from the list. The installer goes through a second request after it is compiled. installer/signpath/ holds the reviewed copies of the two artifact configurations to paste into SignPath.
detect-release-signing.ps1 fails the release when the provider is signpath but a SignPath setting is missing, or when the provider value is unknown, instead of falling back to the certificate or to an unsigned build.
SignPath Foundation requires a page titled "Code signing policy" that carries its attribution, names the committers, reviewers and approvers, and links the privacy policy, referenced from the project home page and the release pages.
docs/code-signing-policy.md states what is signed, the team roles taken from the repository collaborators and the maintainers team, the CI release process that SignPath-signed builds will go through, and the current status: releases up to v0.9.3 were built and signed locally with the Certum certificate. Both READMEs link to it, and publish-release.sh appends the link to the release notes it writes.
release.yml runs the Server job on a persistent self-hosted runner while
ci.yml runs it on a fresh windows-2025 image, so only the release path
kept a MetasequoiaImeServer.exe alive between jobs. That leftover holds
Local\MetasequoiaImeServer_SingleInstance, the Server started by
probe-server.ps1 returns 0 straight out of the guard, and the probe then
completes its handshakes against the older build. Probes 1-4 pass because
they do not ask for CharacterSetShortcut; probe 5 does, the pre-6ff1cff
Server never advertises it, and the run dies on a capability mismatch that
nothing in the tree can explain. v0.6.3 and v0.6.4 both failed this way.
Stop any Server and Watchdog before starting one, and fail loudly if the
Server this script starts exits on its own.
Also stop test-server.ps1 from reporting every non-zero verify-contracts
exit as a lock mismatch. A dubious-ownership git failure on the same
runner surfaced as "The engine submodule does not match the product lock"
while the lock was correct.
Also ignore installer/LICENSE.txt, which Prepare-PackageFiles.ps1
generates from the repository LICENSE on every local packaging run.
Automatic per-merge builds shared one list with deliberately cut releases, and the previous change only made them identifiable rather than separate: both were still prereleases, which is the thing the issue objects to. Labelling was the wrong answer to it.
GitHub has no channel concept, but it has two published states, and there are exactly two kinds of release here. A push-triggered build is now a prerelease; a workflow_dispatch build is an ordinary release and the newest one carries the Latest badge. The Releases page shows two lists instead of one list with two kinds of title in it, and /releases/latest resolves for the first time.
The prerelease flag therefore means "automatic and uncurated" rather than "beta". The product being 内测 is stated in the release notes and in docs/installation.md, which is where a claim about stability belongs; the flag cannot carry that meaning while it is also the only thing separating the channels. docs/installation.md now tells readers to take the Latest badge, describes both channels, and says explicitly that being in the release channel means somebody picked it, not that it is stable.
Already published releases are not touched, so the Latest badge stays empty until the first dispatch after this lands.
Refs MSIME-Windows#167
tokisaki galaxy