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

[Kurt Hornik]

>>>>> Dirk Eddelbuettel writes:

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

Thanks.  As I thought I had written: I now realize that we should have
asked for snapshots to support the API transition and not for new
regular releases.  However, the API transition is now finalized, and we
really need a release that works with R 4.6.0 once this gets released
next week.

It it helps: personally I think that your hotfix snapshots have much
higher test quality than most of the scheduled releases we're seeing
from others.  And we know that the current snapshot caused no new
problems on CRAN.

Best
-k

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