R Xla Release Package

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.

Step 3: Check for Remotes

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.

Step 4: Ask Release Type

Suggest an appropriate release type based on the NEWS.md content:

• If NEWS mentions "breaking changes", "BREAKING", or similar → suggest Major
• If NEWS mentions only "bug fixes", "fixes", "patch" with no new features → suggest Patch
• Otherwise (new features, improvements) → suggest Minor

Use AskUserQuestion to confirm:

Question: "What type of release for <package> (currently <version>)?" Header: "Release type" Options (with recommended option first, marked "(Recommended)"):

• Major (X.0.0)
• Minor (x.X.0)
• Patch (x.x.X)

Calculate the new version:

• Strip .9xxx development suffix first
• Then bump according to release type
• Examples:
  • 0.1.0.9000 + Patch → 0.1.1
  • 0.1.0.9000 + Minor → 0.2.0
  • 0.1.1.9000 + Patch → 0.1.2
  • 1.2.3.9000 + Major → 2.0.0

Display: "Preparing release: <package> <current> → <new version>"

Step 5: Check Git History for Missing NEWS.md Entries

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.

Step 6: Create Release Branch

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:

• Delete it and create a fresh one
• Abort

Step 7: Update DESCRIPTION — Version

Replace the Version: field with the new version (e.g., 0.1.0.9000 → 0.2.0). Use the Edit tool.

Step 8: Update NEWS.md

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.0

Use the Edit tool.

Step 9: Commit and Push

git add DESCRIPTION NEWS.md
git commit -m "$(cat <<'EOF'