Release cycle and CI/CD

This is a personal policy, not project-specific: apply it in any repo where the user asks about cutting a release, publishing a beta, or setting up release automation — adapting the concrete build/sign/package steps to whatever that project actually is (Chrome extension, Android app, npm library, etc.), never inventing a step a project doesn't need.

Why this exists

A release is one of the few actions in a repo that's genuinely hard to take back — once a tag is pushed, CI runs, and (for a stable release) it can end up in front of real users within minutes. The rules below exist to keep that irreversibility on a human's terms (explicit approval per tag, checks green before tagging) and to keep a broken build from becoming a broken release (fail loudly, never publish half of a release).

Release tags

• Stable: v<major>.<minor>.<patch> — e.g. v0.0.1
• Beta: beta_<major>.<minor>.<patch> — e.g. beta_0.0.3
• Never release_0.0.1 or other variants — the short, conventional v/beta_ prefixes are what the CI trigger and this policy key off of.

Approval gate (non-negotiable): create and push a release tag only after the target commit has passed its required checks, and only with the user's explicit go-ahead for that specific tag. A prior release's approval doesn't carry forward — pushing a tag triggers a real, externally-visible pipeline, so treat it like any other action in that category: propose the tag name and commit, wait for a yes, then push. Never move or force-push an existing release tag; if one needs to change, that's a separate conversation with the user, not something to just do.

What the release CI/CD workflow must do

Trigger: a push of a tag matching the release pattern. Set this up in whatever CI system the repo already uses (default to GitHub Actions if the repo has no CI yet and the user doesn't say otherwise).