Cut Release

Cut a MIPVerify release

Run the release as a sequence of independently verified gates. Keep the release commit small, give the release notes the same care as code, and follow the automation through the registry merge and published GitHub release.

Before drafting or approving release notes, read references/release-notes-style.md completely.

Guardrails

• Read and follow the repository AGENTS.md and shared instructions.
• Run gh auth status outside the sandbox before using GitHub. Do not diagnose credentials from a sandboxed check.
• Work on a descriptive branch from current origin/master. Never commit directly on master.
• Preserve unrelated user changes. If the current worktree is dirty, use a clean throwaway worktree or clone instead of stashing, reverting, or mixing changes.
• Treat the release PR merge, Julia registration, General registry merge, tag, and GitHub release as separate gates. Verify each gate before starting the next one.
• Wait for the release PR to merge, resolve its merge commit, and post the JuliaRegistrator request on that commit.
• Let General's automerge and this repository's TagBot workflow operate normally. Do not manually merge the registry PR or create a tag while automation is healthy.
• Preserve every required AI trailer and visible disclosure from the repository instructions. The Registrator commit comment is its own GitHub artifact and needs its own disclosure.

1. Reconcile the current release state

Start by locating any release work that already exists: an open or merged release PR, a version bump on master, a Registrator comment, a General PR, a tag, and a GitHub release. Compare their versions and commit IDs (SHAs) before making changes.

Resume from the first incomplete gate and perform only the gates the user authorized. Do not infer the next version solely from Project.toml: it may already have been bumped for a release that has not been tagged. Reuse verified artifacts instead of opening a duplicate PR, posting a second registration request, or creating a competing tag or release.

2. Establish the release range and version

1. Fetch origin/master and inspect the live repository, latest tag, latest GitHub release, and Project.toml version.
2. Build a complete inventory of changes since the latest release tag from every first-parent commit. Attach PR metadata where a commit came from a PR, and retain direct commits as separate inventory entries. Resolve squash-merge subjects such as ... (#123) back to their PRs.
3. Inspect Project.toml compatibility and search README/docs for version requirements that may have become stale.
4. Choose the next version from the current version and actual changes. Before 1.0, user-visible breaking changes and new user-visible functionality normally require a minor release; compatible bug fixes normally require a patch release. Apply normal semantic-versioning rules after 1.0. Ask only when the change set leaves the choice genuinely ambiguous.
5. Keep feature work out of the release PR. Limit it to release metadata and small, clearly justified release-facing corrections.

Useful read-only starting points include:

git log --first-parent --oneline <previous-tag>..origin/master
gh release view <previous-tag> --repo vtjeng/MIPVerify.jl
gh pr view <number> --repo vtjeng/MIPVerify.jl --json title,body,commits,files,url

3. Research the release changes

Research every inventory entry against its committed diff, implementation, tests, commit history, and any linked evidence. Use subagents when parallel review materially improves coverage: give substantive changes focused ownership, batch trivial related changes when appropriate, and work in waves when concurrency is limited. Do not ask research subagents to edit files or GitHub.

Require a compact result with:

• purpose and user-facing outcome;
• behavior, compatibility, or schema changes;
• correctness and failure-mode implications;
• performance evidence when relevant, including the scope needed to interpret a publishable claim;
• tests, continuous integration (CI), dependency, or maintainer-only scope;
• proposed release-note section and the inventory entries it represents;
• exact claims that need an independent accuracy check.

Maintain the complete change inventory even when several entries become one bullet. Retain purely internal housekeeping in the inventory and mark it as intentionally omitted from the notes.

4. Draft and verify the release notes

1. Read the release-note style reference linked above.
2. Review recent successful releases, then choose the closest precedent for tone and level of detail.
3. Group PRs only when they serve the same user-facing goal. When one bullet contains distinct changes, map each PR to its change in the opening sentence.
4. Choose sentence-case sections from the purposes represented in the current release. Omit empty sections and do not preserve an old release's structure when it no longer fits.
5. Scale review depth to the release. Independently check risky correctness, compatibility, and performance claims against code and evidence; for a substantial release, also use focused passes for coverage, placement, and readability.
6. Resolve every finding and show the complete copy-ready draft to the user before posting it.
7. End the Registrator comment with the repository's visible AI collaboration disclosure.

Do not let a concise rewrite weaken a safety claim, merge separate benchmark experiments, or imply that unrelated work shares one goal. If removing an unverified claim leaves an accurate, useful bullet, omit the claim. Otherwise keep the draft explicitly blocked. Never publish provisional wording as fact.