This guide explains how to create a new release of Whitespace.
GitHub releases work by:
- Creating a git tag (e.g.,
v1.0.0) - Pushing the tag to GitHub
- GitHub Actions automatically builds binaries for all platforms
- A release is created with the binaries attached
-
Ensure you have an NPM account and are logged in:
pnpm login
-
Add the NPM_TOKEN secret to your GitHub repository:
- Go to Settings → Secrets and variables → Actions
- Add a new secret named
NPM_TOKENwith your npm token - Generate a token at: https://www.npmjs.com/settings/YOUR_USERNAME/tokens
-
Update version numbers in:
whitespace-cli/Cargo.tomlwhitespace-core/Cargo.tomlwhitespace-mcp/package.json
-
Commit the version changes:
git add -A git commit -m "Bump version to v1.0.0" git push -
Create and push a tag:
git tag v1.0.0 git push origin v1.0.0
-
GitHub Actions will automatically:
- Build binaries for macOS (Intel & Apple Silicon) and Linux (x86_64 & ARM64)
- Create a GitHub release with the binaries
- Publish the MCP server to npm
You can also trigger a release manually from the GitHub Actions tab:
- Go to Actions → Release workflow
- Click "Run workflow"
- Enter the tag name (e.g.,
v1.0.0) - Click "Run workflow"
For testing release builds locally:
# Build for your current platform
./scripts/build-release.sh v1.0.0
# Output will be in release/v1.0.0/We follow Semantic Versioning (SemVer):
- Major (1.0.0): Breaking changes
- Minor (0.1.0): New features, backward compatible
- Patch (0.0.1): Bug fixes, backward compatible
Pre-release versions:
- Alpha:
v1.0.0-alpha.1 - Beta:
v1.0.0-beta.1 - Release Candidate:
v1.0.0-rc.1
Whitespace consists of three independently versioned components:
- The core component that provides all functionality
- Version defined in
whitespace-cli/Cargo.toml - Released with tags:
cli-v1.0.0
- Node.js wrapper for AI integrations
- Version defined in
whitespace-mcp/package.json - Released with tags:
mcp-v1.0.0 - Must maintain compatibility with CLI version:
- Major version must match CLI exactly
- Minor version must be ≤ CLI minor version
- Patch version is independent
- IDE integration for VS Code and Cursor
- Version defined in
whitespace-vscode/package.json - Released with tags:
vscode-v1.0.0 - Must maintain compatibility with CLI version:
- Major version must match CLI exactly
- Minor version must be ≤ CLI minor version
- Patch version is independent
| CLI Version | MCP/VS Code Version | Compatible? | Reason |
|---|---|---|---|
| 2.3.1 | 2.0.5 | ✅ | Major matches, minor 0 ≤ 3 |
| 2.3.1 | 2.3.9 | ✅ | Major matches, minor 3 ≤ 3 |
| 2.3.1 | 2.4.0 | ❌ | Minor 4 > 3 (might use unavailable features) |
| 2.3.1 | 3.0.0 | ❌ | Major version mismatch |
| 1.0.0 | 1.0.0 | ✅ | Exact match |
Each component has its own release workflow:
# Release CLI
git tag cli-v1.0.0
git push origin cli-v1.0.0
# Release MCP Server
git tag mcp-v1.0.0
git push origin mcp-v1.0.0
# Release VS Code Extension
git tag vscode-v1.0.0
git push origin vscode-v1.0.0Both MCP and VS Code extensions verify CLI compatibility on startup:
# CLI provides version info
whitespace version --output json
# {"name":"whitespace","version":"1.0.0"}If the CLI version doesn't meet requirements, the MCP server and VS Code extension will fail with a clear error message indicating the version mismatch.
The release workflow builds for:
- macOS Intel (x86_64-apple-darwin)
- macOS Apple Silicon (aarch64-apple-darwin)
- Linux x86_64 (x86_64-unknown-linux-gnu)
- Linux ARM64 (aarch64-unknown-linux-gnu)
Each release includes:
whitespace-macos-amd64.tar.gz- macOS Intel binarywhitespace-macos-arm64.tar.gz- macOS Apple Silicon binarywhitespace-linux-amd64.tar.gz- Linux x86_64 binarywhitespace-linux-arm64.tar.gz- Linux ARM64 binary- Source code (automatically included by GitHub)
The MCP server is published to npm as @whitespace/mcp-server.
Users can install it with:
npx @whitespace/mcp-serverIf the release build fails:
- Check the GitHub Actions logs for errors
- Ensure all tests pass locally
- Verify Cargo.toml versions match
If npm publishing fails:
- Verify the NPM_TOKEN secret is set correctly
- Check that the package name is available
- Ensure package.json is valid
For Linux ARM64 builds from x86_64:
- The workflow uses
crossfor cross-compilation - This requires Docker to be available in the CI environment
After a successful release:
- Update the documentation if needed
- Announce the release (optional)
- Start working on the next version!