You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should release builds include a native win-arm64 binary?
Current state
The release matrix (.github/workflows/release.yml) builds three RIDs, one per OS at its dominant arch:
osx-arm64
linux-x64
win-x64
There is no win-arm64 (nor linux-arm64 / osx-x64). The implicit policy today is "one RID per OS, the dominant architecture."
Why this is deferred, not an oversight
Windows-on-ARM already runs the win-x64 binary. WoA ships a built-in x64 emulator, so clet-<ver>-win-x64.zip is functional on Snapdragon X / ARM Surface devices today. The case for a native win-arm64 build is therefore performance (cold-start latency under emulation), not functionality. Our own perf budget cares about this (tests/SPEC.md: "<150ms Windows x64"), but for the current alpha (one clet) it's premature.
The build cost is non-trivial because of AOT. We publish with -p:PublishAot=true --self-contained. ILC cross-compilation to win-arm64 from a win-x64 host is not a clean path; the reliable approach is a native windows-11-arm GitHub runner (now GA). That means a new matrix row, a new runner, and getting the Unit/Integration/Smoke steps green on arm64. Note tests/Directory.Build.props already documents a win-arm64 sharp edge (NETSDK1151), so the RID has its own known rough spots.
Adding it breaks the current symmetry and invites "then why not linux-arm64?" — which should be a deliberate coverage decision, not a one-off.
When it would be worth doing
Once there's actual user demand for native Windows ARM performance, or
When we stand up the Homebrew/WinGet channels at v1.0 GA (Milestone: v1.0 GA — tied to TG v2 GA, channels live #6) and want first-class arm64 packages rather than emulated ones — that's the natural moment, since we're touching the release/packaging surface anyway.
Proposed disposition
Defer past v0.x. Revisit at RC (#5) / GA (#6). If accepted, the work is:
Add a win-arm64 row to the build matrix in release.yml on a windows-11-arm runner.
Confirm AOT publish + Unit/Integration/Smoke pass on arm64.
Add package_windows win-arm64 to the release packaging step and a row to the README download table.
Update specs/clet-spec.md §7 (release) to record the supported-RID policy explicitly.
Question
Should release builds include a native
win-arm64binary?Current state
The release matrix (
.github/workflows/release.yml) builds three RIDs, one per OS at its dominant arch:osx-arm64linux-x64win-x64There is no
win-arm64(norlinux-arm64/osx-x64). The implicit policy today is "one RID per OS, the dominant architecture."Why this is deferred, not an oversight
Windows-on-ARM already runs the
win-x64binary. WoA ships a built-in x64 emulator, soclet-<ver>-win-x64.zipis functional on Snapdragon X / ARM Surface devices today. The case for a nativewin-arm64build is therefore performance (cold-start latency under emulation), not functionality. Our own perf budget cares about this (tests/SPEC.md: "<150ms Windows x64"), but for the current alpha (one clet) it's premature.The build cost is non-trivial because of AOT. We publish with
-p:PublishAot=true --self-contained. ILC cross-compilation towin-arm64from awin-x64host is not a clean path; the reliable approach is a nativewindows-11-armGitHub runner (now GA). That means a new matrix row, a new runner, and getting the Unit/Integration/Smoke steps green on arm64. Notetests/Directory.Build.propsalready documents a win-arm64 sharp edge (NETSDK1151), so the RID has its own known rough spots.Adding it breaks the current symmetry and invites "then why not
linux-arm64?" — which should be a deliberate coverage decision, not a one-off.When it would be worth doing
Proposed disposition
Defer past v0.x. Revisit at RC (#5) / GA (#6). If accepted, the work is:
win-arm64row to thebuildmatrix inrelease.ymlon awindows-11-armrunner.package_windows win-arm64to the release packaging step and a row to the README download table.specs/clet-spec.md§7 (release) to record the supported-RID policy explicitly.