[R] CRAN packaging checklist for version 16.1.0

[thisisnic]

Packaging checklist for CRAN release

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

cc @jonkeane @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

• Nic to email CRAN to confirm change of maintainer
• 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

[assignUser]

This is ready to review and release related #41629

I believe this is also causing the builds we are hosting to be slightly busted. I just tried installing a nightly on arm64 and found that gzip wasn't enabled.

This would mean the binaries on jfrog are affected by this. Do we want to replace them? We also still have the issue with the offline build on CRAN...

[amoeba]

Thanks for starting this off @thisisnic. I noticed that #40388 is still open and I think at least one or two things are still undone (tagging commit for cran submission, update backwards compat job). Do you remember which commit we sent off to CRAN?

We also still have the issue with the offline build on CRAN...

Do we have an issue with next steps? Is this what caused the Mac build to be disabled?

[thisisnic]

Thanks for flagging this up @amoeba! In terms of the commit, it should be the one at the head of the relevant release branch.
I think we need to discuss this with CRAN perhaps, depending on whether it works or not upon the next release. Pinging @jonkeane who had a better idea.

[thisisnic]

@assignUser The issue you linked to, has that ended up just being a CI issue so doesn't affect the release? And can you elaborate on the Jfrog binaries issue, I don't understand exactly what's going on there.

[assignUser]

During the release process that workflow is used to create the binaries that nixlibs.R pulls from. So if the mac binaries there are busted we probably want to switch them for working ones. (which requires the PR to be merged and cherry picked on the cran branch so we can build them)

[thisisnic]

Right, sounds like we probably want to fix it then

[thisisnic]

This will need updating to read 16.1.0, then merging & cherry-picking: #41422

[thisisnic]

@paleolimbot Would you mind doing the revdepcheck pls? I haven't created an R-specific branch yet but I don't think we need to cherry-pick anything over that is code, so the main release branch should be good to use.

[paleolimbot]

I am back on Tuesday and can give it a try then!

[thisisnic]

I am back on Tuesday and can give it a try then!

Fantastic, thanks! Do you reckon you'll have time after that to make it into a Dockerfile like we chatted about a while ago?

[assignUser]

crossbow jobs from r-release branch: #41762

[assignUser]

Ok, that's an issue: https://www.r-project.org/nosvn/R.check/r-release-windows-x86_64/arrow-00install.html
They have turned off network access for the windows build as well.

[nealrichardson]

Ok, that's an issue: https://www.r-project.org/nosvn/R.check/r-release-windows-x86_64/arrow-00install.html They have turned off network access for the windows build as well.

Let's hope that was just a fluke.

[assignUser]

I am going to upload a tarball to winbuilder (though it passing there doesn't really mean anything)

[assignUser]

As expected win builder passed...

[assignUser]

I have tagged the cran commit for 15.0.1. I also merged #41629 and picked it into the release branch (I have dropped that again as it was just affecting the actual nightly package binary not the libarrow binaries) and removed the badges and added the checksums.

edit:
confirmed on mac

*** Checksum validated successfully for libarrow
*** Successfully retrieved libarrow (darwin-arm64-openssl-3.0)
...
Arrow package version: 16.1.0

Capabilities:

acero      TRUE
dataset    TRUE
substrait FALSE
parquet    TRUE
json       TRUE
s3         TRUE
gcs        TRUE
utf8proc   TRUE
re2        TRUE
snappy     TRUE
gzip       TRUE
brotli     TRUE
zstd       TRUE
lz4        TRUE
lz4_frame  TRUE
lzo       FALSE
bz2        TRUE
jemalloc   TRUE
mimalloc   TRUE

[assignUser]

Crossbow jobs look good, the only thing left imo is to update and merge #41422 and then the submission process (+maintainer change). I think we should pro-actively ask about the offline build stuff especially now that it also happens on windows (but I'll leave that up to @jonkeane :) ).

The non-api calls are from cpp11 afaiu? Also it seems those where converted to a note from an error?

That's as far as I can contribute for now, good luck!

[thisisnic]

Thanks @assignUser for your hard work! Once we're ready to submit to CRAN, I'll email about the maintainer change.

The plan regarding the builds is to submit the package, see what happens, and then if we get a hobbled build, then immediately get onto emailing CRAN and/or the dev mailing list. I'd like the maintainer change to happen before we do that.

[thisisnic]

I'd like to do the tweet/whatever thread, as I'd like to briefly mention the maintainer change, if that's OK with you @jonkeane?

[thisisnic]

@paleolimbot How are the revdepchecks looking?

[amoeba]

Re: revdepchecks, I wanted a reason to try out https://github.com/r-devel/recheck so I kicked off https://github.com/amoeba/arrow-r-recheck/actions/runs/9212033245.

[amoeba]

I think the recheck output looks clear but would appreciate another set of eyes. I ran it from the maint-16.1.0-r branch and triggered revdepcheck for strong (depends/imports) and most (depends/imports/suggests).

[assignUser]

Let's hope that was just a fluke.

Looks like it was, the windows check is fine again.

[paleolimbot]

Thanks @amoeba for the reverse dependency check...I'm not sure I ever would have thought of that solution and it is a lot easier than anything I was planning to try!

[jonkeane]

Nic submitted the package and I've confirmed.

I just got the (automated, pre-test email that flagged Notes in two builds) https://win-builder.r-project.org/incoming_pretest/arrow_16.1.0_20240525_151425/Windows/00check.log https://win-builder.r-project.org/incoming_pretest/arrow_16.1.0_20240525_151425/Debian/00check.log

For both of these:
One NOTE is the maintainer change (which we know about)

* checking CRAN incoming feasibility ... [5s/7s] NOTE
Maintainer: ‘Jonathan Keane <[email protected]>’

New maintainer:
  Jonathan Keane <[email protected]>
Old maintainer(s):
  Nic Crane <[email protected]>

One NOTE is the so-called non-API calls.

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

I believe these are "ok" because other packages with cpp11 dependencies (e.g. systemfonts) have been submitted and passed with these.

One other thing that's slightly more worrying is:

Found the following (possibly) invalid file URIs:
  URI: articles/read_write.html
    From: README.md
  URI: articles/data_wrangling.html
    From: README.md
  URI: reference/acero.html
    From: README.md
  URI: articles/install.html
    From: README.md
  URI: articles/install_nightly.html
    From: README.md

[jonkeane]

Those possibly invalid URIs look like they were introduced in #40148 (and so this is the first CRAN submission with them here)

I'm a little surprised that we don't see them in our as-cran check though: https://github.com/ursacomputing/crossbow/actions/runs/9231423983/job/25401288490

[jonkeane]

I'm trying to replicate those in CI at #41828 looking at r-lib/devtools#2054 though, from Jenny:

Replace any internal links in your README with a full URL to GitHub (or perhaps a pkgdown site).

[thisisnic]

I made a PR and cherry-picked those commits to the maint-16.0.1-r branch and submitted that to CRAN.

[thisisnic]

@assignUser Did we fix the binaries you mentioned earlier? I noticed the checksums were updated on the branch a few days ago so wasn't sure if it was that?

[assignUser]

Yes that's fine, it was only affecting the actual nightly package binaries not the libarrow binaries.

[jonkeane]

I made a #41830 and cherry-picked those commits to the maint-16.0.1-r branch and submitted that to CRAN.

Thanks Nic, I just got the second email back and the only notes in the auto-check are ones we expect (change in maintainer, and the cpp11 ones that happen to anyone using cpp11).

[jonkeane]

And thank you everyone for y'alls help here 🙏

[jonkeane]

Should we move the r-universe-release tag now, or wait until we actually get to CRAN?

[jonkeane]

arrow_16.1.0.tar.gz is on its way to CRAN.

Also up at https://cran.r-project.org/web/packages/arrow/index.html

[jonkeane]

I also just bumped the r-universe-release tag to the maintenance branch

[thisisnic]

Thanks for doing the r-universe tag @jonkeane, we should add that to our release checklist.

IMO we should just tag it for r-universe when we have done the various steps to submit to CRAN as we can move it later if necessary, and at that point we are confident enough about the package that any changes needed are very CRAN-oriented rather than release-specific. Keen to hear what other folks think though, there may be good reasons to hang back.

[assignUser]

Keen to hear what other folks think though, there may be good reasons to hang back.

👍 I thought about bumping it when I created the branch but it seemed to early as we were missing the news still, but tagging it once we are release ready (regardless if on cran or not) seems like a good point to do it :)

Looks like the build is failing in the actual package build on oldrel intel with no actual error visible... I'll try to replicate on gha.

[assignUser]

I was of course unable to reproduce, there are a bunch of warnings which I assume to be env specific or they would have shown up on cran as well https://github.com/assignUser/test-repo-a/actions/runs/9239685590/job/25419135479#step:3:552

[assignUser]

And the error is gone again?

[assignUser]

but also 😕

Arrow package version: 16.1.0

Capabilities:

acero      TRUE
dataset    TRUE
substrait FALSE
parquet    TRUE
json       TRUE
s3        FALSE
gcs       FALSE
utf8proc   TRUE
re2        TRUE
snappy     TRUE
gzip      FALSE
brotli    FALSE
zstd      FALSE
lz4        TRUE
lz4_frame  TRUE
lzo       FALSE
bz2       FALSE
jemalloc  FALSE
mimalloc   TRUE

edit: I think this is only possible if LIBARROW_MINIMAL is unset when build_arrow_static.sh is run? Which just is the case if the var is not set as we check for it but only actively set it if not_cran. Not sure why it wouldn't also show like this on the mac builder?

[thisisnic]

I pushed both tags r-16.1.0 and r-universe-release (oops, sorry, didn't see Jon had done this already, though I guess it needed moving after we updated those links). We should add the latter to our checklist.
We should also add a link to Bryce's script for the contributor calculation for the social media thread.

[thisisnic]

We should also remove the text which refer to previous steps which Jeroen did as I got tripped up skim-reading and not realising the steps were still valid even if those bits aren't any more