Skip to content

Add section on releasing to CRAN#285

Open
d-morrison wants to merge 9 commits into
mainfrom
claude/issue-277-20260520-2320
Open

Add section on releasing to CRAN#285
d-morrison wants to merge 9 commits into
mainfrom
claude/issue-277-20260520-2320

Conversation

@d-morrison

Copy link
Copy Markdown
Member

Adds a "Releasing to CRAN" section to code-publication.qmd covering versioning, pre-release checklist, CRAN submission, and post-acceptance steps including git tagging and GitHub releases.

Closes #277

Generated with Claude Code

Adds a new "Releasing to CRAN" section to code-publication.qmd covering
versioning, pre-release checklist, CRAN submission, and post-acceptance
steps including git tagging and version bumping.

Closes #277

Co-authored-by: Douglas Ezra Morrison <d-morrison@users.noreply.github.com>
@d-morrison

Copy link
Copy Markdown
Member Author

@claude add the diagram from https://github.com/edgararuiz-zz/cran-stages (with attribution)

@claude

claude Bot commented May 29, 2026

Copy link
Copy Markdown
Contributor

Claude finished @d-morrison's task in 4m 39s —— View job


Adding CRAN Stages Diagram

Tasks:

Done! Added the CRAN stages diagram to code-publication.qmd right after the opening paragraph of the "Releasing to CRAN" section.

What was added (lines 128–130 of the updated file):

The diagram below illustrates the stages of the CRAN submission pipeline:

![](https://github.com/edgararuiz-zz/cran-stages).](https://raw.githubusercontent.com/edgararuiz-zz/cran-stages/master/cran-stages.png){fig-alt="..."}

Note: The image is referenced via raw.githubusercontent.com using the master branch. If the image doesn't render correctly (e.g., if the default branch is main instead of master, or if the filename differs), the URL can be updated by changing master to main or adjusting the filename. You can verify the correct path by checking the repository file listing.
|

Co-authored-by: Douglas Ezra Morrison <d-morrison@users.noreply.github.com>
@d-morrison

Copy link
Copy Markdown
Member Author

@claude fix failing workflows

@claude

claude Bot commented Jun 2, 2026

Copy link
Copy Markdown
Contributor

Claude finished @d-morrison's task in 5m 33s —— View job


Fixed Failing Workflows

Root Causes Found and Fixed:

Workflow Cause Fix
Check Links https://raw.githubusercontent.com/edgararuiz-zz/cran-stages/master/cran-stages.png returns 404 (archived account) Replaced broken image with a text link to the repository
Quarto Preview Same 404 URL — Quarto fails when it can't fetch the image during PDF rendering Same fix (image removal)
Check Non-Standard Characters Em dashes (—) at lines 157–158 of code-publication.qmd Replaced em dashes with ASCII hyphens

Changes made in commit 93d992b:

  • Replaced the broken external image reference with a descriptive sentence and hyperlink to the cran-stages repository by Edgar Ruiz
  • Replaced em dashes () with ASCII hyphens (-) in two lines of the pre-release checklist

Tasks:

  • Analyze request
  • Check CI status and identify failing workflows
  • Read changed files and identify root causes
  • Fix broken image URL (replaced with text link + attribution)
  • Fix em dashes in lines 157-158
  • Commit and push changes

Note on remaining failures:

  • Check Bibliography DOIs - Pre-existing bug: the R script receives all bib file paths as a single concatenated string, causing it to treat them as one filename. This is unrelated to this PR's changes.
  • Check Non-Standard Characters - The other 23 files with em dashes/curly quotes are pre-existing issues not introduced by this PR.
  • Claude Code Review - Unrelated automated review step.
    |

- Replace broken external image (404) with a text description and
  hyperlink to the cran-stages repository by Edgar Ruiz
- Replace em dashes with ASCII hyphens in the pre-release checklist

Co-authored-by: Douglas Ezra Morrison <d-morrison@users.noreply.github.com>
Copilot AI review requested due to automatic review settings June 2, 2026 04:52
@d-morrison d-morrison removed the request for review from Copilot June 2, 2026 04:52
@github-actions

github-actions Bot commented Jun 2, 2026

Copy link
Copy Markdown
Contributor
PR Preview Action v1.8.1-2-g6ad689f

QR code for preview link

🚀 View preview at
https://UCD-SERG.github.io/lab-manual/pr-preview/pr-285/

Built to branch gh-pages at 2026-06-18 03:02 UTC.
Preview will be ready when the GitHub Pages deployment is complete.

@d-morrison

Copy link
Copy Markdown
Member Author

@claude review

@claude

claude Bot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Claude finished @d-morrison's task in 1m 13s —— View job


Code Review

Tasks:

  • Read PR diff
  • Read file context
  • Analyze content for correctness, completeness, and style
  • Post review

Overall Assessment

The new "Releasing to CRAN" section is well-structured, practical, and covers the most important steps in a logical order. The writing is clear and the code examples are helpful. A few items worth addressing:


Issues

1. rhub::check_for_cran() is deprecated (Medium)

code-publication.qmd, line ~162

The rhub package underwent a major rewrite in v2 (released 2023). rhub::check_for_cran() no longer exists in rhub v2; the new approach is GitHub Actions-based:

# New rhub v2 workflow:
rhub::rhub_setup()   # run once to add a GitHub Actions workflow
rhub::rc_submit()    # trigger a check run

Alternatively, the R-hub GitHub Actions workflow can be set up manually. Leaving the deprecated function name will confuse users who have rhub v2 installed.

Fix this →


2. devtools::check() missing cran = TRUE (Minor)

code-publication.qmd, line ~146

For CRAN submissions, devtools::check(cran = TRUE) is recommended — it enables stricter checks that more closely mirror what CRAN runs. The bare devtools::check() call may miss some CRAN-specific notes.

devtools::check(cran = TRUE)

Fix this →


Suggestions

3. Consider adding urlchecker::url_check() (Minor)

The R Packages book pre-release checklist recommends running urlchecker::url_check() to catch broken URLs in documentation. Given that this PR itself had a broken image URL issue, this feels especially relevant for your lab's workflow.

4. Slight duplication with "Create Github release" section above

The "After CRAN Acceptance" subsection restates the git tag and GitHub release steps that already appear in the ## Create Github release section above. Consider cross-referencing that section instead:

2. **Create a GitHub release**: Follow the steps described in the
   [Create Github release](#create-github-release) section above.

5. Submission comments note is slightly inaccurate

"In your submission comments (prompted by devtools::submit_cran())"

devtools::submit_cran() opens the CRAN web submission form in a browser rather than prompting inline. The guidance is correct in spirit, but the phrasing implies an interactive prompt. Consider: "On the CRAN web form that opens, briefly describe..."


What's Working Well

  • Clear versioning scheme with concrete before/after examples
  • Step-by-step pre-release checklist is actionable
  • Post-acceptance steps (tag → release → dev bump) are in the right order and the development suffix convention is explained well
  • Good attribution to Edgar Ruiz for the CRAN stages diagram and to Wickham/Bryan for r-pkgs.org
  • Quarto cross-reference anchor {#sec-cran-release} is a nice touch

| Branch

@d-morrison

Copy link
Copy Markdown
Member Author

Claude Code CLI (local session) is working on this — paws off until I'm done.

- Replace deprecated rhub::check_for_cran() with the rhub v2 GitHub
  Actions workflow (rhub::rhub_setup() / rhub::rc_submit()).
- Use devtools::check(cran = TRUE) for stricter CRAN-aligned checks.
- Add urlchecker::url_check() to the pre-release checklist.
- Cross-reference the 'Create Github release' section instead of
  restating the tag/release steps under 'After CRAN Acceptance'.
- Clarify that submit_cran() opens a web form rather than prompting
  inline.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings June 3, 2026 22:17
@d-morrison

Copy link
Copy Markdown
Member Author

Addressed all five items from the latest review:

  1. rhub deprecation (Medium): replaced rhub::check_for_cran() with the rhub v2 GitHub Actions workflow (rhub::rhub_setup() once, then rhub::rc_submit()), and noted the old function was removed in the v2 rewrite.
  2. devtools::check(cran = TRUE) (Minor): updated the pre-release check call to enable the stricter CRAN-aligned checks.
  3. urlchecker::url_check() (Suggestion): added as a new pre-release checklist step.
  4. Duplication with 'Create Github release' (Suggestion): the 'After CRAN Acceptance' steps now cross-reference the Create Github release section instead of restating the tag/release steps; subsequent steps renumbered.
  5. submit_cran() phrasing (Suggestion): reworded to 'On the CRAN web submission form that devtools::submit_cran() opens...' rather than implying an inline prompt.

@claude review

@claude

claude Bot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Claude finished @d-morrison's task in 1m 59s —— View job


Code Review

Tasks:

  • Analyze request
  • Read current code-publication.qmd
  • Verify all 5 items from previous review are addressed
  • Check for any new issues
  • Post review

Previous Review Items — Status

# Item Status
1 rhub deprecation ✅ Fixed
2 devtools::check(cran = TRUE) ✅ Fixed
3 urlchecker::url_check() ✅ Added
4 Duplication with "Create Github release" ✅ Cross-referenced
5 submit_cran() phrasing ✅ Reworded

All five items are addressed. The section reads well overall.


New Issue Found

rhub::rc_submit() does not exist in rhub v2 (Medium — my error from the previous review)

code-publication.qmd, line 162

I apologize — my previous review incorrectly specified rhub::rc_submit() and this was faithfully implemented. That function does not exist in the rhub package. The correct rhub v2 function is rhub::rhub_check():

# Correct rhub v2 usage:
rhub::rhub_setup()  # run once to add the GitHub Actions workflow
rhub::rhub_check()  # trigger a check run

rhub::rc_submit() will throw Error: could not find function "rc_submit" for any user who follows this guide.

Fix this →


What's Working Well

  • The versioning scheme (major.minor.patch + .9000 dev suffix) is clearly explained with concrete examples
  • All six pre-release checklist steps are actionable and correctly ordered
  • The cross-reference to "Create Github release" cleanly avoids duplication
  • The submit_cran() guidance is accurate: it submits programmatically, then an email confirmation is sent
  • usethis::use_version("dev") is the right way to bump to the dev version
  • The post-acceptance 3-step flow (tag → bump version → commit) is correct

| Branch

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds guidance to the lab manual’s “Code Publication” chapter for releasing an R package to CRAN, aligning with Issue #277’s request to summarize and link to the R Packages CRAN release chapter and to include lab-specific tagging/release details.

Changes:

  • Introduces a new “Releasing to CRAN” section covering versioning, pre-release checks, submission, and post-acceptance steps.
  • Adds links to CRAN resources and the R Packages CRAN release guidance.

Comment thread code-publication.qmd Outdated
Comment thread code-publication.qmd Outdated
Comment thread code-publication.qmd Outdated
Comment thread code-publication.qmd Outdated
@d-morrison

Copy link
Copy Markdown
Member Author

Claude Code CLI (local session) is working on this — paws off until I'm done.

The line paired rhub_setup() (which configures the GitHub Actions
workflow) with rc_submit() (the separate R Consortium runners path).
rhub_check() is the function that triggers a run via the workflow that
rhub_setup() installs, so the two now describe one coherent workflow.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@d-morrison

Copy link
Copy Markdown
Member Author

Addressed the new review item.

rhub function (line 162): Replaced rhub::rc_submit() with rhub::rhub_check().

Note for the record: rc_submit() does still exist in rhub v2 — it submits to the R Consortium runners (paired with rc_new_token()), so it wouldn't throw "could not find function". But the line described the GitHub Actions workflow (rhub_setup()), and rhub_check() is the function that triggers a run via that workflow. rc_submit() belongs to a separate mechanism, so pairing rhub_setup()rhub_check() is the correct, coherent fix.

@claude review

@claude

claude Bot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Claude finished @d-morrison's task in 1m 48s —— View job


Code Review

Tasks:

  • Analyze request
  • Read current code-publication.qmd
  • Check git diff for latest changes
  • Review for remaining issues
  • Post review

Previous Review Items — Status

# Item Status
1–5 Prior review items ✅ All fixed
6 rhub::rc_submit()rhub::rhub_check() ✅ Fixed — and d-morrison's explanation is accurate

The rhub fix is correct. rhub::rhub_setup()rhub::rhub_check() is the coherent GitHub Actions workflow pair; rc_submit() belongs to the separate R Consortium runner mechanism and would have been a misleading non-sequitur after rhub_setup().


On the Copilot Reviewer's Remaining Flags

Version numbering (copilot's line 196 comment) — Not a real bug

The copilot reviewer said 1.2.0.9000 should be 1.2.1.9000 after releasing 1.2.0. This is incorrect. usethis::use_version("dev") appends .9000 to the current released version without incrementing the patch component: 1.2.01.2.0.9000. This matches the R Packages book convention and is what the function actually does. The text is correct as written.

Long prose lines (copilot's line 127 and 184 comments) — Minor / cosmetic

Lines 124, 126–127, and 184 are long single-line paragraphs. The copilot reviewer asked for semantic line breaks to make diffs easier to review. This hasn't been addressed, but it's a style preference rather than a correctness issue. Example of what they're asking for, applied to lines 126–127:

The CRAN submission pipeline goes through several stages:
initial upload, automated checks, human review by CRAN maintainers, and final acceptance or rejection.
For a visual overview of the full pipeline,
see the [CRAN stages diagram](https://github.com/edgararuiz-zz/cran-stages) by Edgar Ruiz.

Missing blank line before nested list (copilot's line 163 comment) — Very minor

Line 160 ends with "Use the following to test on additional platforms:" and the nested bullet list follows immediately with no blank line. This renders correctly in pandoc/Quarto (tight lists within ordered list items are handled), so it's not a functional issue — just cosmetic style consistency.


Overall Assessment

The section is accurate, well-structured, and actionable. The two outstanding copilot style flags (long lines, missing blank line) are cosmetic. The version numbering is correct. The content is ready for merge as-is; whether to address the line-wrapping style before merging is your call.
| Branch

@d-morrison

Copy link
Copy Markdown
Member Author

Claude Code CLI (local session) is working on this — paws off until I'm done.

Address remaining Copilot style flags on the CRAN release section:
- Wrap the long intro paragraph (CRAN section) and the 'After CRAN
  Acceptance' tag-the-release item into semantic line breaks, matching the
  repo's one-clause-per-line convention.
- Add a blank line before the nested platform-test bullet list in step 5.

The flagged 1.2.0.9000 -> 1.2.1.9000 version bump is intentionally left as-is:
usethis::use_version('dev') appends .9000 without incrementing the patch, so
1.2.0 -> 1.2.0.9000 is correct.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings June 3, 2026 22:58
@d-morrison

Copy link
Copy Markdown
Member Author

Addressed the remaining Copilot style flags (commit 3c1e8b6):

  • Long prose lines (lines 124, 184) — wrapped into semantic line breaks (one clause per line) to match the repo convention used elsewhere.
  • Missing blank line before nested list in pre-release step 5 (line 160) — added.

On the version-numbering flag (line 196 / 1.2.0.9000 vs 1.2.1.9000): left as-is, because the current text is correct. usethis::use_version("dev") appends .9000 to the current released version without incrementing the patch component — verified against the usethis docs: "increments to a development version, e.g. from 1.0.0 to 1.0.0.9000." So after releasing 1.2.0, the dev version is 1.2.0.9000, exactly as written. Changing it to 1.2.1.9000 would make the example contradict what the function actually does.

The rhub v2 fix from the prior round (rhub_setup() + rhub_check()) is confirmed correct.

@claude review

@d-morrison

Copy link
Copy Markdown
Member Author

Done with my local session — unclaiming. (Re-triggered @claude review on the latest commit.)

@claude

claude Bot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Claude finished @d-morrison's task in 1m 38s —— View job


Code Review

Tasks:

  • Analyze request
  • Read CLAUDE.md
  • Review git diff from origin/main
  • Read current code-publication.qmd
  • Verify style fixes (semantic line breaks, blank line before list)
  • Check for any remaining issues
  • Post review

Copilot Style Flags — Status

Flag Status
Long intro paragraph (line 124) ✅ Wrapped into semantic line breaks
Long "After CRAN Acceptance" item 1 (line 184) ✅ Wrapped into semantic line breaks
Missing blank line before nested list in step 5 ✅ Blank line added
Version number 1.2.0.9000 vs 1.2.1.9000 ✅ Left as-is — confirmed correct (see below)

All four Copilot flags are now resolved.


On the Version Number

d-morrison's reasoning is correct and backed by the usethis docs: usethis::use_version("dev") appends .9000 to the current released version without touching the patch number. So releasing 1.2.0 → dev version is 1.2.0.9000, not 1.2.1.9000. The example in the text matches what the function actually does. The Copilot reviewer's flag was incorrect.


Overall Assessment

The section is accurate, well-structured, and all flagged issues are resolved. The semantic line breaks match the repo convention, the blank line before the nested list renders reliably in Pandoc/Quarto, and the technical content (rhub v2, devtools::check(cran = TRUE), urlchecker::url_check(), version bumping) is correct.

This section is ready to merge.


| Branch

@claude

claude Bot commented Jun 3, 2026

Copy link
Copy Markdown
Contributor

Claude finished @d-morrison's task in 1m 15s —— View job


Code Review

Tasks:

  • Analyze request
  • Read current code-publication.qmd
  • Check git diff for latest changes
  • Review for remaining issues
  • Post review

Previous Review Items — Final Status

# Item Status
1 rhub deprecation → rhub_setup() + rhub_check() ✅ Fixed
2 devtools::check(cran = TRUE) ✅ Fixed
3 urlchecker::url_check() ✅ Added
4 Duplication with "Create Github release" ✅ Cross-referenced
5 submit_cran() phrasing ✅ Reworded
6 rhub::rc_submit()rhub::rhub_check() ✅ Fixed
7 Long prose lines (Copilot style flag) ✅ Semantic line breaks applied
8 Missing blank line before nested list in step 5 ✅ Fixed
9 Version numbering 1.2.0.9000 (Copilot flag) ✅ Correctly left as-is

No New Issues

The latest commit (3c1e8b6) correctly applies semantic line breaks to the intro paragraph (lines 124–128), the pipeline description (lines 130–131), and the "After CRAN Acceptance" step 1 (lines 189–194). The blank line before the nested bullet list in step 5 is present. All content is accurate.

A quick check on the items that generated debate:

  • Version numbering (1.2.01.2.0.9000): Confirmed correct — usethis::use_version("dev") appends .9000 to the current released version without incrementing the patch number.
  • rhub workflow (rhub_setup() then rhub_check()): Correct — this is the coherent GitHub Actions pair for rhub v2.
  • devtools::submit_cran() description: The note about the CRAN web submission form is accurate and the phrasing is clear.

Overall Assessment

The "Releasing to CRAN" section is accurate, well-structured, and ready for merge. All review items from all rounds are resolved. The section covers versioning, pre-release checks, submission, and post-acceptance steps in the right order with correct function names and references.


| Branch

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 7 comments.

Comment thread code-publication.qmd Outdated
Comment thread code-publication.qmd
3. **Commit the version bump**: Stage and commit the updated `DESCRIPTION` (and `NEWS.md` if you added a `# mypackage (development version)` header):
```bash
git add DESCRIPTION NEWS.md
git commit -m "Start development toward next release (1.2.0.9000)"
Comment thread code-publication.qmd Outdated
Comment thread code-publication.qmd Outdated
Comment thread code-publication.qmd Outdated
Comment thread code-publication.qmd Outdated
Comment thread code-publication.qmd Outdated
@d-morrison

Copy link
Copy Markdown
Member Author

@claude address #285 (review)

@claude

claude Bot commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

Claude finished @d-morrison's task in 7m 14s —— View job


Addressed Copilot Review #pullrequestreview-4423402337

Tasks:

  • Analyze request and review comments
  • Read current code-publication.qmd and repo guidelines
  • Fix "Github" → "GitHub" throughout the file (checklist line 14, "Clean up feature branches" para, header line 116, "Create Github release" para line 118)
  • Add {#sec-create-github-release} label to header; update checklist link anchor; replace (#create-github-release) in CRAN section with @sec-create-github-release
  • Fix line 196 description: "increment the patch version" was wrong — use_version("dev") appends .9000 WITHOUT incrementing the patch; description now matches the example (1.2.0.9000)
  • Apply semantic line breaks: lines 130–131, 135, 147, 149, 156–163, 173, 178, 181, 183, 197–228
  • Fix temporal reference on line 167: "As of rhub v2" → "In rhub v2"
  • Commit and push

Summary of changes (commit 1157724)

Item Change
"Github" → "GitHub" Lines 14, 114, 116, 118
{#sec-create-github-release} label Added to ## Create GitHub release header
Checklist link Updated anchor from #create-github-release#sec-create-github-release
Cross-reference in CRAN section Replaced [Create Github release](#create-github-release) with @sec-create-github-release
Temporal phrase "As of rhub v2" → "In rhub v2"
Version-bump description (line 196) Removed "increment the patch version and" — use_version("dev") does NOT increment the patch; it appends .9000 to the current version (1.2.01.2.0.9000)
Semantic line breaks Applied throughout the CRAN section
Version numbers (1.2.0.9000) Left as-is — confirmed correct in prior review rounds
Branch

github-actions Bot and others added 2 commits June 10, 2026 03:30
…fs, fix version-bump description

- Apply semantic line breaks throughout the CRAN section (lines 130-131, 135, 147,
  149, 156-158, 160-163, 173, 178, 181, 183, 197-228) per repo convention
- Fix "Github" → "GitHub" in checklist, header, and paragraph (lines 14, 114, 116, 118)
- Add {#sec-create-github-release} label to the "Create GitHub release" header
- Update checklist link to use new anchor (#sec-create-github-release)
- Replace manual (#create-github-release) cross-reference in CRAN section
  with Quarto @sec-create-github-release cross-reference
- Fix line 167 temporal phrase: "As of rhub v2" → "In rhub v2"
- Fix line 196 description: "increment the patch version and add .9000" was wrong;
  usethis::use_version("dev") appends .9000 WITHOUT incrementing the patch
  (1.2.0 → 1.2.0.9000, not 1.2.1.9000); description now matches the example

Addresses pullrequestreview-4423402337

Co-authored-by: Douglas Ezra Morrison <d-morrison@users.noreply.github.com>
Copilot AI review requested due to automatic review settings June 17, 2026 06:24

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 4 comments.

Comment thread code-publication.qmd Outdated
which will tag the repository,
creating a marker at this specific point in time.

Detailed instructions [here.](https://docs.github.com/en/enterprise/2.13/user/articles/creating-releases)
Comment thread code-publication.qmd Outdated
Comment on lines +184 to +187
In rhub v2, this runs via GitHub Actions:
run `rhub::rhub_setup()` once to add the workflow to your repository,
then `rhub::rhub_check()` to trigger a check run.
(The older `rhub::check_for_cran()` function was removed in the v2 rewrite.)
Comment thread code-publication.qmd Outdated
Comment thread code-publication.qmd
you may want to release it on [CRAN](https://cran.r-project.org/) (the Comprehensive R Archive Network).
This section summarizes the release process
and adds lab-specific guidance on versioning and tagging.
For full details, see the [R Packages book chapter on releasing to CRAN](https://r-pkgs.org/release.html) by Hadley Wickham and Jennifer Bryan.
@d-morrison

Copy link
Copy Markdown
Member Author

Claude Code CLI (local session) is working on this — paws off until I'm done.

@d-morrison

Copy link
Copy Markdown
Member Author

@claude review

@claude

claude Bot commented Jun 17, 2026

Copy link
Copy Markdown
Contributor

Claude finished @d-morrison's task in 2m 3s —— View job


Code Review

Tasks:

  • Analyze request
  • Read CLAUDE.md for repo conventions
  • Read current code-publication.qmd
  • Review new Copilot flags from 2026-06-17
  • Post review findings

New Copilot Flags — Assessment

The latest Copilot review (2026-06-17) raised four items. Here's my assessment of each:


1. GitHub Enterprise 2.13 link (line 123) — Real issue, fix recommended

code-publication.qmd, line 123:

Detailed instructions [here.](https://docs.github.com/en/enterprise/2.13/user/articles/creating-releases)

This URL is pinned to GitHub Enterprise 2.13 (released ~2018). The page may already be stale or inaccessible. The canonical URL for the current GitHub docs on managing releases is:

Detailed instructions [here.](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository)

The link text is also worth improving — here. with the period inside the brackets is awkward; something like [Creating Releases](...) would be clearer. Copilot's flag is valid.

Fix this →


2. "Annotated tag" claim (line 219) — Real technical inaccuracy, fix required

code-publication.qmd, line 219:

using an annotated tag named `v` followed by the version number (e.g., `v1.2.0`).

The cross-referenced section (@sec-create-github-release) directs users to the GitHub UI. However, the GitHub UI creates lightweight tags, not annotated tags. Annotated tags require git tag -a v1.2.0 -m "Release v1.2.0" to be run explicitly. Telling users to use "an annotated tag" while pointing them at the GitHub UI is a technical contradiction.

For CRAN releases, annotated tags are better practice (they store tagger, date, and message as separate Git objects). If the intent is to require annotated tags, explicit CLI instructions should be provided:

git tag -a v1.2.0 -m "Release v1.2.0"
git push origin v1.2.0

Otherwise, remove the word "annotated" from line 219. Copilot's flag is valid and this is the most significant issue remaining.

Fix this →


3. rhub v2 claims without reference (lines 184–187) — Valid suggestion, low priority

Lines 184–187 make specific claims about rhub v2 behavior (GitHub Actions-based, rhub_setup() / rhub_check(), and that check_for_cran() was removed) without a supporting link. Adding a link to the rhub v2 vignette would let readers verify the guidance independently and signal where to look if the API changes again. Copilot's flag is valid as a forward-looking maintainability concern, though the content itself is correct.

Fix this →


4. Long sentence at line 131 — Not worth addressing

Line 131 is already a single, well-formed sentence that fits naturally on one line. The semantic line break convention is applied throughout the surrounding paragraphs (lines 127–130, 133–138). This one remaining sentence is not egregiously long and is lower priority than items 1–3. Skipping this is fine.


Summary

# Item Assessment
1 GitHub Enterprise 2.13 link ✅ Fix — replace with canonical docs URL
2 "Annotated tag" claim ✅ Fix — real technical inaccuracy; remove "annotated" or add git tag -a instructions
3 rhub v2 without reference Consider — add link to rhub v2 vignette for forward compatibility
4 Long line 131 Skip — acceptable as-is

Items 1 and 2 are the blockers. Item 3 is a nice-to-have. Otherwise the section is accurate and well-structured.
| Branch

- Replace stale GitHub Enterprise 2.13 releases URL with canonical docs URL
  and clearer link text.
- Drop 'annotated' (the cross-referenced GitHub UI creates lightweight tags).
- Link the rhub v2 vignette for the rhub v2 guidance.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@d-morrison

Copy link
Copy Markdown
Member Author

@claude review

@claude

claude Bot commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

Claude finished @d-morrison's task in 1m 29s —— View job


Code Review

Tasks:

  • Analyze request
  • Read current code-publication.qmd
  • Check git diff from origin/main
  • Review for remaining issues from previous review rounds
  • Post findings

Previous Review Items — Final Status

The latest commit (1364751) addressed all three flagged issues from the 2026-06-17 review round:

# Item Status
1 Stale GitHub Enterprise 2.13 link ✅ Fixed — replaced with canonical Managing releases in a repository URL; link text improved from here. to descriptive text
2 "Annotated tag" claim contradicting GitHub UI ✅ Fixed — removed "annotated"; now reads "using a tag named v followed by the version number"
3 rhub v2 guidance without reference ✅ Fixed — rhub v2 is now a hyperlink to the rhub v2 vignette
4 Long line 131 ✅ Skipped (acceptable as-is per prior consensus)

All prior review items across all rounds are resolved.


No New Issues

A fresh read of the full section found nothing new to flag. Spot-checks on items that generated debate in earlier rounds:

  • Version numbering (1.2.01.2.0.9000): Correct — usethis::use_version("dev") appends .9000 to the current released version without incrementing the patch.
  • rhub workflow (rhub_setup() + rhub_check()): Correct — coherent GitHub Actions pair for rhub v2; now backed by the vignette link.
  • devtools::check(cran = TRUE): Present and correct.
  • urlchecker::url_check(): Present and correct.
  • Cross-reference (@sec-create-github-release): Correct Quarto syntax; matches the {#sec-create-github-release} label on the header.
  • submit_cran() phrasing: Accurate.
  • Semantic line breaks: Applied throughout; consistent with repo convention.

Overall Assessment

The "Releasing to CRAN" section is accurate, well-structured, and all flagged issues from all review rounds are resolved. This section is ready to merge.
| Branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

add a section on releasing to cran

2 participants