Prepare a release of a single R package. Use when the user says "release this package", "bump version", "cut a release", or wants to publish a new version of the current R package. Must be run from inside the package directory (contains a DESCRIPTION file).
Your role is to prepare a release of a single R package.
DESCRIPTION file. If not,
inform the user this must be run from an R package root directory and stop.gh is available and authenticated:
gh repo view --json url
If not, suggest gh auth login and stop.Read DESCRIPTION and extract the Package: and Version: fields.
Read the first section of NEWS.md (everything under the first # heading
up to the next # heading) to understand what changes are included.
Display to the user:
Package: <name>
Version: <current version>
NEWS.md: <first heading>
Then show the NEWS.md content for the upcoming release so the user can review it.
Check whether DESCRIPTION contains a Remotes: field. If it does, the package
cannot be released to CRAN with remote dependencies.
For each remote listed, look up the latest release version on CRAN (or the package's repository if not on CRAN) and suggest replacing the remote dependency with a minimum version requirement.
Display the remotes to the user:
Remotes found in DESCRIPTION:
- <owner>/<repo>
- <owner>/<repo2>
Use AskUserQuestion to ask which minimum version to require for each package.
Suggest the latest released version of each package as the default.
Once the user confirms, remove the Remotes: field from DESCRIPTION and update
the corresponding entries in Imports: or Depends: to include the agreed
version requirements (e.g., package (>= x.y.z)).
If there are no Remotes: entries, skip this step silently.
Suggest an appropriate release type based on the NEWS.md content:
Use AskUserQuestion to confirm:
Question: "What type of release for <package> (currently <version>)?"
Header: "Release type"
Options (with recommended option first, marked "(Recommended)"):
Calculate the new version:
.9xxx development suffix first0.1.0.9000 + Patch → 0.1.10.1.0.9000 + Minor → 0.2.00.1.1.9000 + Patch → 0.1.21.2.3.9000 + Major → 2.0.0Display: "Preparing release: <package> <current> → <new version>"
Find the last release tag and list commits since then:
LAST_TAG=$(git tag --sort=-version:refname | head -1)
if [ -n "$LAST_TAG" ]; then
git log "${LAST_TAG}..HEAD" --oneline --no-merges
else
git log --oneline --no-merges
fi
Compare commits against NEWS.md entries. Look for commits describing user-facing changes (new features, bug fixes, behaviour changes) without a corresponding NEWS entry.
Ignore purely internal commits: CI changes, linting, dependency bumps without user-visible effect, merge commits.
If there are likely missing entries, summarise them for the user and ask whether to add them to NEWS.md before proceeding.
git checkout main
git pull origin main
git checkout -b release/<version>
If a release/* branch already exists, ask the user how to proceed using
AskUserQuestion:
Replace the Version: field with the new version (e.g., 0.1.0.9000 → 0.2.0).
Use the Edit tool.
Replace the development version header with the release version.
The header format is: # <package> (development version)
Replace with: # <package> <version>
For example:
# anvil (development version) → # anvil 0.2.0Use the Edit tool.
git add DESCRIPTION NEWS.md
git commit -m "$(cat <<'EOF'