Scott Hanselman 882937299a docs: remove stale WinForms references, update test counts and capabilities

- README.md: Fix project table (OpenClaw.Tray → OpenClaw.Tray.WinUI),
  remove WinForms run command, add system.run.prepare and system.which
  to capability table and allowCommands JSON, remove '(investigating)'
  from canvas.a2ui commands
- DEVELOPMENT.md: Remove OpenClaw.Tray/ from structure, add
  OpenClaw.Tray.Tests/, update test counts (88 → 571), fix CI section
- build.ps1: Fix broken 'Tray' target to point at WinUI .csproj,
  remove WinForms from default build and run instructions
- docs/VERSIONING.md: Remove reference to deleted OpenClaw.Tray.csproj
- docs/TEST_COVERAGE.md: Full rewrite (88 → 571 tests, .NET 9 → 10)
- docs/CODE_REVIEW.md: Update project names, test counts, .NET version
- docs/WINDOWS_NODE_TESTING.md: Mark system.run as implemented, update
  capability descriptions
- docs/WINDOWS_NODE_ARCHITECTURE.md: Add historical planning note,
  update current state table (Node mode now implemented)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

2026-03-17 20:38:13 -07:00

3.1 KiB

Raw Permalink Blame History

Versioning in OpenClaw Windows Hub

How Versioning Works

This project uses GitVersion for automatic semantic versioning based on git tags and commit history. The version is used in multiple places:

Version Properties in .csproj

The project file (OpenClaw.Tray.WinUI.csproj) defines only the <Version> property:

<Version>0.3.0</Version>

Other version-related properties (FileVersion and AssemblyVersion) are not explicitly set in the csproj files. This is intentional.

Automatic Version Derivation

When only <Version> is set in a .NET project:

AssemblyVersion: Automatically set to the numeric part of Version (e.g., 0.3.0 → 0.3.0.0)
FileVersion: Automatically set to the numeric part of Version (e.g., 0.3.0 → 0.3.0.0)
InformationalVersion: Set to the full Version value including suffixes (e.g., 0.3.0-beta.1)

This ensures all version properties stay in sync automatically.

CI Build Process

During CI builds (.github/workflows/ci.yml), GitVersion determines the semantic version from git history and passes it to the build:

dotnet build -p:Version=${{ needs.test.outputs.semVer }}

This -p:Version=... argument overrides the <Version> property in the csproj, and consequently also sets FileVersion and AssemblyVersion to match.

Auto-Updater Version Detection

The Updatum auto-updater determines the current application version by reading the AssemblyVersion from the running executable using:

Assembly.GetExecutingAssembly().GetName().Version

This is why it's critical that AssemblyVersion (and FileVersion) match the semantic version - otherwise, the updater will get confused and keep offering the same update repeatedly.

Historical Issue

Previously, the csproj files had hardcoded values:

<Version>0.3.0</Version>
<FileVersion>0.2.0</FileVersion>
<AssemblyVersion>0.2.0</AssemblyVersion>

This caused a version mismatch:

The semantic version was 0.3.0
But the file and assembly versions were stuck at 0.2.0
Updatum would read 0.2.0 from the running EXE
It would see 0.4.0 available on GitHub
It would offer to update from "0.2.0" to "0.4.0" even though the user was already on 0.3.0 or 0.4.0

Solution

By removing the hardcoded FileVersion and AssemblyVersion properties, they now automatically derive from Version. When CI overrides Version via command-line, all three properties are set correctly and consistently.

Best Practices

Never hardcode FileVersion or AssemblyVersion in the csproj - let them auto-derive from Version
Let GitVersion and CI control the version - the csproj's <Version> is just a fallback for local development builds
Test version detection - after building, check the EXE properties to ensure FileVersion matches expectations
Use semantic versioning - tags should follow v{major}.{minor}.{patch} format (e.g., v0.4.0)

3.1 KiB Raw Permalink Blame History