Skip to content

RELEASING.md

Latest commit

 

History

History
79 lines (53 loc) · 2.4 KB

RELEASING.md

File metadata and controls

79 lines (53 loc) · 2.4 KB
Raw

Releasing

NullClaw uses CalVer with the format YYYY.M.D (e.g., v2026.3.12).

Pushing a tag matching v* triggers the Release workflow, which calls the shared nullclaw/nullbuilder Zig release workflow. It builds binaries for all supported platforms and publishes a GitHub Release.

Nightly builds

The Nightly workflow runs at 02:23 UTC every day and can also be started manually from GitHub Actions. It delegates the build matrix and artifact packaging to nullclaw/nullbuilder.

Nightly builds:

  • build ReleaseSmall binaries for the same target matrix as releases
  • upload per-target artifacts with SHA-256 files and a small JSON manifest
  • keep artifacts for 14 days
  • do not create GitHub Releases, move tags, or publish Docker images
  • skip scheduled duplicate work when the current main commit already has a successful nightly run

Use the manual force input if you need to rebuild the same commit intentionally.

Steps

  1. Checkout and update main

    git checkout main
git pull origin main

  2. Create a release branch

    git checkout -b release/vYYYY.M.D

  3. Bump the version in build.zig.zon

    Update the .version field to match today's date:

    - .version = "2026.3.11",
+ .version = "2026.3.12",

  4. Commit the version bump

    git add build.zig.zon
git commit -m "vYYYY.M.D"

  5. Tag and push the branch

    git tag vYYYY.M.D
git push origin release/vYYYY.M.D --tags

    The tag push triggers CI builds. If builds fail, fix on the branch, move the tag, and push again:

    # after fixing and committing:
git tag -f vYYYY.M.D
git push origin release/vYYYY.M.D --tags --force

  6. Create a PR once builds pass

    gh pr create --title "vYYYY.M.D" --body "Version bump for vYYYY.M.D release."

  7. Merge the PR (or get it reviewed and merged)

Notes

  • The tag is created on the release branch so CI builds run before merging to main. This avoids having to push fixes directly to main if builds fail.
  • If multiple releases happen on the same day, append a patch number (e.g., v2026.3.12.1), though this should be rare.
  • NullHub follows the same versioning and release process. Both repos should be released together with matching version numbers.