cut-release

name	cut-release
description	Cut a new tagged release of the ha-rbac integration. Use when asked to "release", "cut a release", "ship a version", or publish a new vX.Y.Z. Covers the version scheme, the fact that manifest.json is bumped automatically by CI (never by hand), the commit and release-notes conventions, and how to verify the release landed.

Cutting a release of ha-rbac

A release is a GitHub release with a vX.Y.Z tag. Publishing it triggers .github/workflows/release.yml, which sets manifest.json's version from the tag and commits it as github-actions[bot]. That is the whole delivery mechanism — HACS serves the tagged commit.

The one thing that trips people up

Do not edit custom_components/ha_rbac/manifest.json's version yourself. The release workflow does it from the tag name (v0.13.0 → 0.13.0) and pushes a Set version to vX.Y.Z commit afterwards. If you bump it by hand you get a duplicate/conflicting change. Your job is to commit the content and create the release; the version follows the tag.

Version scheme

• Tags are v-prefixed semver: v0.13.0.
• Still 0.x (alpha). A normal change — feature or fix — is a minor bump (0.12.0 → 0.13.0). Reserve a patch bump for a same-day follow-up to a release that shipped broken.
• Check the last tag first: git tag --sort=-creatordate | head -1.

Steps

1. Be releasable. On main, working tree clean-ish, and green:

   .venv/bin/python -m pytest -q
   uvx ruff check . && uvx ruff format --check .