[Rcpp-devel] [External] Re: CRAN package Rcpp

[Dirk Eddelbuettel]

On 31 March 2026 at 19:45, Kurt Hornik wrote:
| >>>>> Dirk Eddelbuettel writes:
| 
| > On 31 March 2026 at 19:03, Kurt Hornik wrote:
| > | Of course, this is "only a NOTE" which normally we would not ask to fix
| > | immediately, but in the course of the next regular update.  However, as
| > | I wrote in my original message, about 300 CRAN packages are currently
| 
| > You could consider silencing the NOTE now if it goes to far. Or add a
| > whitelist of tolerated NOTEs at package update. As I understand, you use
| > environment variables for that type of conditioning for other
| > 'choices'.
| 
| Luke can speak for himself, but I guess we really want package code to
| stop using R_UnboundValue "as quickly as possible" ... it was never part
| of the API, and should never have been used in package code.
| 
| We can always do an NMU for Rcpp if a hotfix release is too much trouble
| on your end?

We pursue two goals here. Number one is to _always_ keep our main git branch
in a releasable state, which we also make available via e.g. r-universe. We
have a decent track record on this. And a release affects three thousand
packages directly and a few thousand more recursively. So we stick to goal
number two as well: have a predictable release plan, and pattern, and execute
it. Both approaches have worked well for us given our resources.

My *strong* preference therefore remains the same as it was the previous
times base R changes broke things requiring last minutes actions: you are
cordially invited to the use GitHub version from the master branch in all
your test setups. That will quieten the NOTE. It may even make sense in the
context of R-devel.  But that is NOT the same as suggesting and even making a
release. The less exposure you give such a modified version, the fewer
'surprises' may come back to us.

So applying a single patch to the last actual release may be the least bad
option. As said, I would also prefer it if that version stayed local to the
CRAN _test machines_ as opposed to whole mirrored archive as it is not
release we plan, validate, or make.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org