[Rcpp-devel] [External] Re: Removing declaration for non-API variable R_NamespaceRegistry (fwd)

Dirk Eddelbuettel edd at debian.org
Fri Apr 17 16:12:22 CEST 2026


(Added rcpp-devel which in hindsight I should have done earlier in this
thread. Silly me always thought reason might prevail.)

Kurt,

On 17 April 2026 at 15:25, Kurt Hornik wrote:
| >>>>> Dirk Eddelbuettel writes:
| 
| Dirk,
| 
| Thanks for the thanks ...

My pleasure.
 
| I think we've learned a lot from the R 4.6.0 API transition.  I also

I am not sure I can agree with that. I might if I saw progress towards better
processes.  So far all I see is a few people "wishing for a pony on a
rainbow" that makes the issue go away. No proposals. No changes. This is
third time you are forcing us with a literal knife at our throat to make a
release we would rather not make out of bands.  

| still like the idea of having a transitional package area to facilitate
| all kinds of transitions (caused by changes in R itself, R packages or
| system packages).  As you said, it is important to distinguish such
| hotfixes from versions "really released" (including the x.y.0/Other area
| which is really meant to packages really released but depending on a yet
| unreleased version of R), and clearly when we need transitional versions
| of non-CRAN (i.e., BioC) packages, we need to avoid having these seen as
| "pubslihed" on CRAN.
| 
| Having said that, we went into code freeze for the R 4.6.0 release, so
| that transition should now get finalized and the hotfixes replaced by
| new release versions.  In particular, the current Rcpp release version
| on CRAN will no longer install with r-release once R 4.6.0 is released
| Fri in a week.
| 
| So can you please set the wheels in motion to provide a new Rcpp release
| along with the R 4.6.0 release?

I really do not want to, and I dislike what is happening here.

I am finalizing an RcppArmadillo release (to CRAN) which now phases out the
transitional headers we introduces to aid away from C++11. We took over six
months to transition this. 

Team Rcpp will ponder.

Dirk

| 
| Best
| -k
| 
| 
| 
| > Luke, Kurt,
| 
| > This is indeed a topic with a lot of scope for further discussion.  But I
| > would like to thank Kurt for adding src/contrib/Transit containing the
| > handful of non-release packages you now require for testing.  The key, in my
| > eyes, remain that testing and development are not required to force
| > themselves onto the current CRAN package release set. Having candidate
| > packages is better.
| 
| > With my Rcpp hat, I am glad you have Rcpp 1.1.1-1 (in /Transit) for testing
| > for those very last-minute changes, but that all users can still rely on the
| > tested stability of Rcpp 1.1.1 (in src/contrib/).  Those who want and can
| > test with development versions can as always use what is at GitHub and
| > R-universe, current 1.1.1.9.
| 
| > I just hotfixed CRANberries. One of the hourly updates propagates Rcpp along
| > with the BioC packages and whatnot is in Transit/ as 'New' but that will not
| > happen again. Similarly, I just told r2u to skip these too so we will not see
| > r2u binaries for Ubuntu 22.04 / 24.04 / 26.04 (latter two arm64 and
| > amd64). That is the way it should: updates for development quality assurance
| > as needed, releases unaffected.
| 
| > Cheers, Dirk
| 
| > -- 
| > Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com

-- 
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com


More information about the Rcpp-devel mailing list