[R] CRAN packaging checklist for version 16.0.0

[jonkeane]

Packaging checklist for CRAN release

For a high-level overview of the release process see the
Apache Arrow Release Management Guide.

cc @thisisnic @amoeba @nealrichardson @assignUser @paleolimbot for coordination on the various tasks to release

Before the release candidate is cut

• Create a GitHub issue entitled [R] CRAN packaging checklist for version X.X.X and copy this checklist to the issue.
• Review deprecated functions to advance their deprecation status, including removing preprocessor directives that no longer apply (search for ARROW_VERSION_MAJOR in r/src).
• Evaluate the status of any failing nightly tests and nightly packaging builds. These checks replicate most of the checks that CRAN runs, so we need them all to be passing or to understand that the failures may (though won't necessarily) result in a rejection from CRAN.
• Check current CRAN check results
• Ensure the contents of the README are accurate and up to date.
• Run urlchecker::url_check() on the R directory at the release candidate.
  commit. Ignore any errors with badges as they will be removed in the CRAN release branch.
• Polish NEWS but do not update version numbers (this is done automatically later). You can find commits by, for example, git log --oneline aa057d0..HEAD | grep "\[R\]"
• Run preliminary reverse dependency checks using archery docker run r-revdepcheck.
• For major releases, prepare tweet thread highlighting new features.

Wait for the release candidate to be cut:

After release candidate has been cut

• Create a CRAN-release branch from the release candidate commit

Prepare and check the .tar.gz that will be released to CRAN.

• git fetch upstream && git checkout release-X.X.X-rcXX && git clean -f -d
• Run make build. This copies Arrow C++ into tools/cpp, prunes some
  unnecessary components, and runs R CMD build to generate the source tarball.
  Because this will install the package, you will need to ensure that the version
  of Arrow C++ available to the configure script is the same as the version
  that is vendored into the R package (e.g., you may need to unset ARROW_HOME).
• devtools::check_built("arrow_X.X.X.tar.gz") locally
• Run reverse dependency checks using archery docker run r-revdepcheck.

Release vote

• Release vote passed!

Generate R package to submit to CRAN

• If the release candidate commit updated, rebase the CRAN release branch
  on that commit.
• Pick any commits that were made to main since the release commit that
  were needed to fix CRAN-related submission issues identified in the above
  steps.
• Remove badges from README.md
• Run urlchecker::url_check() on the R directory
• Create a PR entitled WIP: [R] Verify CRAN release-10.0.1-rc0. Add
  a comment @github-actions crossbow submit --group r to run all R crossbow
  jobs against the CRAN-specific release branch.
• Run Rscript tools/update-checksums.R <libarrow version> to download the checksums for the pre-compiled binaries from the ASF artifactory into the tools directory.
• Regenerate arrow_X.X.X.tar.gz (i.e., make build)

Ensure linux binary packages are available:

• Ensure linux binaries are available in the artifactory:
  https://apache.jfrog.io/ui/repos/tree/General/arrow/r

Check binary Arrow C++ distributions specific to the R package

• Upload the .tar.gz to win-builder (r-devel only)
  and confirm (with Nic, who will automatically receive an email about the results) that the check is clean.
  This step cannot be completed before Jeroen has put the binaries in the MinGW repository, i.e. here, here, and here.
• Upload the .tar.gz to MacBuilder
  and confirm that the check is clean
• Check install.packages("arrow_X.X.X.tar.gz") on Ubuntu and ensure that the
  hosted binaries are used
• devtools::check_built("arrow_X.X.X.tar.gz") locally one more time (for luck)

CRAN submission

• Upload arrow_X.X.X.tar.gz to the
  CRAN submit page
• Confirm the submission email

Wait for CRAN...

• Accepted!
• Tag the tip of the CRAN-specific release branch
• Add a new line to the matrix in the backwards compatability job
• (patch releases only) Update the package version in ci/scripts/PKGBUILD, dev/tasks/homebrew-formulae/autobrew/apache-arrow.rb, r/DESCRIPTION, and r/NEWS.md
• (CRAN-only releases) Rebuild news page with pkgdown::build_news() and submit a PR to the asf-site branch of the docs site with the contents of arrow/r/docs/news/index.html replacing the current contents of arrow-site/docs/r/news/index.html
• (CRAN-only releases) Bump the version number in r/pkgdown/assets/versions.json, and update this on the the asf-site branch of the docs site too.
• Update the packaging checklist template to reflect any new realities of the
  packaging process.
• Wait for CRAN-hosted binaries on the
  CRAN package page to reflect the
  new version
• Tweet!

Component(s)

R

[jonkeane]

This release will be slightly different since it will include the change in maintainer. IIUC We'll need to do:

• Explain any change in the maintainer’s email address and if possible send confirmation from the previous address (by a separate email to CRAN-submissions@R-project.org) or explain why it is not possible.
  If the package needs special treatment (for example if vignettes can only be run or re-built on the maintainer’s machine or take a very long time), say so on the submission form.

from https://cran.r-project.org/web/packages/policies.html#Submission-1

[jonkeane]

Status of current check results

• There are two errors on macos — both are libtool. Which are resolved by GH-40248: [R] fallback to the correct libtool when we find a GNU one #40259 which was not included in the last submission.
• We have a number of notes about using SETLENGTH and SET_TRUELENGTH IIUC, this is CRAN attempting to cut down on people using so called non-API functions. I believe these are coming from vctrs or cpp11 (oddly cpp11 checks are clean, even though they definitely have those

Note: we will need to figure out if we need to resolve #41398 before we can submit to CRAN. The current windows check is on 4.4.0 — that doesn't compile from source there anyway so so long as #41398 is truly a warning -> error situation, we should ok to ship without it.

[nealrichardson]

Re: #41398, I suspect we do need to fix it before releasing, unless we're not updating the libarrow binaries. It's raising on a line that was changed since 15.0: https://github.com/apache/arrow/pull/39888/files#diff-dd3ca7b08e6c9982fcc1be7ea36c93a2d7998ed3ff6bab2ae1e0343ada0358d3R53

The reason we have -Werror on that CI job is because CRAN will cause problems if there are compiler warnings thrown, so we want to be alerted earlier.

Re: the so-called non-API functions, I wonder if those are related to ALTREP, and if they'll go away once newer R-devel builds cycle through after the policy was clarified?

[jonkeane]

Re: the so-called non-API functions, I wonder if those are related to ALTREP, and if they'll go away once newer R-devel builds cycle through after the policy was clarified?

We haven't been running recent R devel versions in our CI (though #41403 is correcting that). I do still see these in that run with a recent (2024-04-24, after the rollback IIUC) R devel:

* checking compiled code ... NOTE
File 'arrow/libs/arrow.so':
  Found non-API calls to R: 'SETLENGTH', 'SET_TRUELENGTH'
Compiled code should not call non-API entry points in R.
See 'Writing portable packages' in the 'Writing R Extensions' manual.

https://github.com/apache/arrow/actions/runs/8861870567/job/24334197361?pr=41403#step:5:4078

[paleolimbot]

I believe the SET_TRUELENGTH and SETLENGTH usage is all from cpp11 headers (which I don't think are checked on CRAN for cpp11, but I see the same note for things like vroom that link to it). I don't see an issue or PR about it in cpp11...I would like to think that CRAN would not make us responsible for that but 🤷 .

[thisisnic]

I submitted a PR for the NEWS updates: #41422

[assignUser]

I have marked #41409 as a blocker for 16.0.1 and will merge it soon (which brings up the question if we want to get #41403 with the minimum version bump in as well and just release 16.0.1? afaik we haven't received any deadlines?)

[thisisnic]

Closing this as we all agreed to wait for 16.1.0 which we'll be doing shortly, though let's move some of these discussions over to the new tickets as they'll be relevant