Add release workflow and releasing docs

.github/workflows/release.yml

@@ -0,0 +1,52 @@
+name: Release
+
+on:
+  push:
+    tags:
+      - "v*"
+
+jobs:
+  release:
+    name: Cut release ${{ github.ref_name }}
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+    steps:
+      - name: Checkout tag
+        uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+          fetch-tags: true
+
+      - name: Validate tag and resolve major
+        id: vars
+        run: |
+          TAG="${GITHUB_REF#refs/tags/}"
+          VERSION="${TAG#v}"
+
+          if ! echo "$VERSION" | grep -qE '^[0-9]+\.[0-9]+\.[0-9]+$'; then
+            echo "::error::Invalid tag format: $TAG (expected vMAJOR.MINOR.PATCH)"
+            exit 1
+          fi
+
+          MAJOR="${VERSION%%.*}"
+          echo "tag=$TAG" >> "$GITHUB_OUTPUT"
+          echo "major=v$MAJOR" >> "$GITHUB_OUTPUT"
+
+      - name: Configure git
+        run: |
+          git config user.name "github-actions[bot]"
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+
+      - name: Move floating major tag forward
+        run: |
+          git tag -f "${{ steps.vars.outputs.major }}" "${{ steps.vars.outputs.tag }}"
+          git push origin "${{ steps.vars.outputs.major }}" --force
+
+      - name: Create GitHub Release
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          gh release create "${{ steps.vars.outputs.tag }}" \
+            --title "${{ steps.vars.outputs.tag }}" \
+            --generate-notes

RELEASING.md

@@ -0,0 +1,29 @@
+# Releasing
+
+This document describes how to cut a new release of `linear-release-action`.
+
+## When to release
+
+Cut a new release whenever `main` has changes that should be picked up by consumers — most commonly after bumping the default `cli_version` in [`action.yml`](./action.yml) to track a new [`linear-release` CLI](https://github.com/linear/linear-release) release.
+
+## How to release
+
+From a clean `main` checkout that's up to date with `origin/main`, push a `vMAJOR.MINOR.PATCH` tag:
+
+```bash
+git checkout main && git pull
+git tag v0.7.2
+git push origin v0.7.2
+```
+
+That triggers the [Release workflow](./.github/workflows/release.yml), which:
+
+1. Validates the tag format.
+2. Force-updates the floating `v<major>` tag (e.g. `v0`) to the same commit so consumers using `linear/linear-release-action@v0` pick up the change automatically.
+3. Creates a GitHub Release with auto-generated notes from the merged PRs since the previous tag.
+
+## Notes
+
+- Consumers reference this action as `linear/linear-release-action@v0` (the floating major tag), so the major-tag move in step 2 is the load-bearing step. Without it, consumers stay on whichever commit the major tag previously pointed to.
+- The action has no version-bearing file in the repo — the source of truth for the action's version is the git tag itself.
+- The CLI version that the action installs at runtime is controlled by [`action.yml`'s `cli_version` default](./action.yml). To bump it, open a regular PR updating `action.yml` and `README.md`, merge, then cut a new action release with the steps above.