Create a CRAN release
Use the repository's two-stage workflow: submit from an open release branch,
then publish the GitHub Release from main only after CRAN acceptance.
Establish the release target
- Read
AGENTS.mdand.github/workflows/submit-cran.yaml. - Verify GitHub authentication, fetch
origin, and preserve unrelated local changes. Use a clean worktree when needed. - Query CRAN for the latest version actually published. Cross-check it against
DESCRIPTION, open release pull requests, and GitHub tags and releases. - If resuming an existing release branch, pull request, or rejected submission, keep its target version. Do not increment past it or create a duplicate.
- When starting a new release and the user has not specified the release type,
ask whether it is
patch,minor, ormajor. Compute the new version from the CRAN-published version, not from an unaccepted submission. - Start a new
release-x.y.zbranch from the latestorigin/mainonly when no matching release is already in flight.
Prepare and validate
Review commits and merged pull requests since the latest CRAN release and the existing development section in
NEWS.md. Do not invent changes.Synchronize the target version in
DESCRIPTION, the firstNEWS.mdheading, andcodemeta.json; remove any development.9000suffix.Keep NEWS concise and user-facing. Omit routine dependency, lint, formatting, CI, and generated-file maintenance.
Update
cran-comments.mdaccurately. Mention a CRAN issue only when the repository evidence supports it.Do not refresh dependencies merely because this is a release.
Run the complete release gate:
air format . --check make lint make hooks make check git diff --checkClean build artifacts, inspect the complete diff, commit the validated release state, and push the release branch. Only then open or update a ready-for-review pull request against
main; its title must contain the exact textCRAN Releaseand its body must describe the final net diff and validation.Wait for every required check to pass. Address, reply to, and resolve every actionable review thread. After each fix, rerun the affected validation, commit and push it, and re-fetch the live thread and check state.
Submit while the pull request stays open
Keep the
CRAN Releasepull request open. Verify that the worktree is clean and the remote release-branch SHA matches the validated localHEAD, then dispatch the package workflow from that branch:gh workflow run submit-cran.yaml --ref release-x.y.zFind and watch the resulting run. On a non-default branch, the reusable workflow must build and submit to CRAN while the GitHub Release job is skipped. Inspect the logs and verify that no tag or GitHub Release was created. Record the workflow run's head SHA as the exact submitted commit.
If submission fails, fix it on the same release branch and retry only after the updated pull request checks are green.
When submission succeeds, report the exact version and workflow run, remind the maintainer to confirm the CRAN email, and stop. Submission success and email confirmation are not CRAN acceptance.
Never merge the pull request, create a tag, or create a GitHub Release until the user explicitly states that CRAN accepted the package.
Publish only after CRAN acceptance
- After the user explicitly reports acceptance, verify that CRAN publishes the target version.
- Squash-merge the
CRAN Releasepull request and verify thatmaincontains the accepted version. - Dispatch
submit-cran.yamlfrommainand watch it to completion. On the default branch, the reusable workflow must skip CRAN submission, resolve the most recently merged matchingCRAN Release <version>pull request, and rebuild and publish from that pull request's original submitted head SHA. - Verify that the tag targets the recorded submitted SHA, not a later
maintree; the source tarball is attached; and the release body is the complete matchingNEWS.mdversion section verbatim. Never use generated release notes or summarize NEWS.