[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