release-sidecar

# Releasing a New Version ## Prerequisites - Go installed matching go.mod version - Clean working tree (`git status` shows no changes) - All tests passing (`go test ./...`) - **Go CI green on `main`** — see "Lint" below; `go test` alone is not the gate - GitHub CLI authenticated (`gh auth status`) - No `replace` directives in go.mod - GoReleaser configured (`.goreleaser.yml` in repo root) - `HOMEBREW_TAP_TOKEN` secret exists in GitHub repo settings **Beware of go.work**: A parent `go.work` file can silently use local dependencies instead of published versions. Always use `GOWORK=off` when updating dependencies and testing builds. ### Lint `.github/workflows/go-ci.yml` runs **two** jobs on every push to `main`: `go test ./...` *and* `golangci-lint` over the whole codebase. Passing tests locally does not mean the release is clean. Local linting is a trap worth knowing about: `.golangci.yml` is a **v2** config, and a v1 `golangci-lint` refuses to read it — ``` Error: you are using a configuration file for golangci-lint v2 with golangci-lint v1 ``` CI pins **v2.8.0**. If your local binary is v1.x, `make lint` fails on the config before linting anything. Either install v2.8.0 to match, or just let CI be the gate: ```bash gh run list --workflow=go-ci.yml --limit=1 # must be "completed success" for the commit you're tagging ``` `make lint` only lints changes since `main`; `make lint-all` covers the full codebase (which is what CI does). ## Release Process ### 1. Deter...