Hi Dirk,

On 09-07-2023 21:09, Dirk Eddelbuettel wrote:
So this is where R 4.3.[01] will possibly break with some older packages.
But the fix is simple because when R 4.3.0 came out all packages at CRAN
complied. We need to have current packages that correspond to the R 4.3.0
standard.

(If one were super picky one could call this an ABI/API change and reason for
forcing _all_ packages to be rebuild. I never advocated for that but I am
getting tired of this process. But we need to throw that bomb at some point
just say 'fsck it' and rebuild _all_ packages. Feels like overkill but so is
wasting weeks on this.

Reading this a second time, I think your proposal is to acknowledge that r-base sometimes introduces unanticipated changes, and if we want to be on the safe side, we should rebuild everything when the minor version bumps. I guess that's more or less (I'm not sure how different r is in that respect) what other interpretation based languages like python, ruby, php and perl are doing too. r-base already has a "handle" for that: r-api-*. We *could* decide to just bump that on every minor bump of r-base and that would mean a transition every time that happens (mostly like those other languages except ruby, python and php also have a "defaults" package to explicitly switch from one version to the next), but at least our tools would help there. Apart from the potential overkill, the major (current) drawback is that for arch:all binaries, we still need source-full uploads as binNMU's don't work for them.

Is that what you are proposing? (For next time maybe?)

Paul

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to