What Is the Release Cycle for OpenClaw Windows Node?

OpenClaw Windows Node follows a tag-driven, CI-automated release cycle that combines GitVersion-based semantic versioning with GitHub Actions to build, test, sign, and publish artifacts.

The openclaw/openclaw-windows-node repository manages releases through a fully automated pipeline triggered by Git tags. Understanding the release cycle for openclaw-windows-node is essential for maintainers shipping new versions and for evaluating the stability of prerelease builds. All release logic is codified in .github/workflows/ci.yml and documented in docs/RELEASING.md.

The Four-Phase Release Process

The release cycle consists of four distinct phases: preparation, tagging, CI execution, and post-release verification. Each phase includes specific validation gates to ensure only signed, tested artifacts reach the public.

Phase 1: Preparation and Cleanup

Maintainers begin by synchronizing a clean master branch. This ensures the release originates from the exact state of the remote repository, eliminating local artifacts that could contaminate the build.

Run these commands from the repository root:

# Ensure a clean master branch

git switch master
git fetch origin master --prune
git reset --hard origin/master
git clean -fd
git status --short --branch

Before tagging, verify that .github/workflows/ci.yml contains the required release policies for executable signing and installer generation:

Select-String .github/workflows/ci.yml -Pattern `
  "Verify Release Executable Signing Policy", `
  "OpenClaw.Tray.WinUI.exe", `
  "build-msix:", `
  "Paused for alpha"

Phase 2: Version Tagging with GitVersion

OpenClaw Windows Node uses GitVersion to derive semantic versions directly from Git history. Maintainers create annotated tags to trigger the release pipeline.

For stable releases, use the format vX.Y.Z. For prereleases, append -alpha.N:

$tag = "v0.6.0-alpha.4"
if ((git rev-parse HEAD) -ne (git rev-parse origin/master)) {
    throw "HEAD is not origin/master; abort."
}
git tag -a $tag -m "OpenClaw Windows Hub $tag"
git push origin $tag

Tagging immediately triggers the CI workflow configured in /.github/workflows/ci.yml.

Phase 3: Automated CI Execution

The GitHub Actions pipeline runs five sequential jobs defined in .github/workflows/ci.yml:

1. repo-hygiene – Validates linting rules and checks for stray .squad files.
2. test – Executes unit tests gated by the OPENCLAW_RUN_INTEGRATION environment variable.
3. e2etests – Runs integration, UI, and functional end-to-end tests.
4. build – Compiles Win-x64 and Win-ARM64 binaries.
5. release – Downloads artifacts, signs executables using scripts/Test-ReleaseExecutableSignatures.ps1, validates native dependencies via scripts/Test-ReleaseNativeDependencies.ps1, creates ZIP payloads, builds Inno Setup installers, signs installers, and publishes the GitHub release.

The release job automatically derives the semantic version from the tag and injects it into artifact names, ensuring traceability from binary back to source tag.

Phase 4: Post-Release Verification

After the CI completes, maintainers verify the published assets match the source tag and contain valid digital signatures:

# View the release metadata

gh release view $tag --repo openclaw/openclaw-windows-node `
  --json tagName,isPrerelease,isLatest,url,assets

# Verify executable signatures

.\scripts\Test-ReleaseExecutableSignatures.ps1 `
  -PayloadPath artifacts/tray-win-x64 `
  -RequireSignedOpenClaw

Verification confirms that prerelease flags are set correctly for alpha builds, that OpenClaw.Tray.WinUI.exe carries a valid signature, and that third-party binaries remain unsigned as expected.

Key Configuration Files

Several files codify the release cycle policies:

• docs/RELEASING.md – Contains the human-readable release checklist and exact PowerShell commands for maintainers.
• /.github/workflows/ci.yml – Implements the job orchestration, gating logic, and release automation.
• GitVersion.yml – Configures the GitVersion tool to generate SemVer strings from Git tags without manual version bumping.
• docs/VERSIONING.md – Documents the semantic versioning policy and tag naming conventions.
• scripts/Test-ReleaseExecutableSignatures.ps1 – Validates that only OpenClaw-owned executables are signed.
• scripts/Test-ReleaseNativeDependencies.ps1 – Ensures required native runtimes (VC-runtime, libsodium) are present in the payload.

Summary

The release cycle for openclaw-windows-node is fully automated and traceable:

• Tag-driven: Releases originate from annotated Git tags following SemVer conventions (vX.Y.Z or vX.Y.Z-alpha.N).
• CI-gated: The .github/workflows/ci.yml pipeline enforces testing, building, signing, and packaging before any artifacts publish.
• Signature-validated: Every release undergoes mandatory signature verification via Test-ReleaseExecutableSignatures.ps1.
• Documented: All procedures are recorded in docs/RELEASING.md and docs/VERSIONING.md.

Frequently Asked Questions

How does OpenClaw Windows Node handle version numbering?

The project uses GitVersion to automatically calculate semantic versions based on Git history. According to docs/VERSIONING.md, maintainers do not manually bump version numbers in code files; instead, they create annotated tags (e.g., v0.6.0-alpha.4), and the CI pipeline injects the computed version into build artifacts during the release job.

What distinguishes stable releases from alpha releases?

Stable releases use the format vX.Y.Z without suffixes, while alpha prereleases append -alpha.N (e.g., v0.6.0-alpha.4). The CI workflow automatically sets the isPrerelease flag on GitHub releases for alpha tags, and the docs/RELEASING.md checklist includes specific steps for verifying alpha-specific policies before publishing.

Where are the signing and validation scripts located?

The repository stores release verification scripts in the scripts/ directory. Test-ReleaseExecutableSignatures.ps1 validates that OpenClaw.Tray.WinUI.exe and other first-party binaries carry valid digital signatures, while Test-ReleaseNativeDependencies.ps1 confirms required dependencies like the VC-runtime and libsodium are included in the final payload.

Can I monitor the release pipeline in real time?

Yes. Use the GitHub CLI to watch the Build and Test workflow execute after pushing a tag:

gh run list --repo openclaw/openclaw-windows-node `
  --workflow "Build and Test" `
  --limit 10

This command displays the status of the repo-hygiene, test, build, and release jobs defined in .github/workflows/ci.yml.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}