On 2024-09-23 4:13 p.m., Ben Bolker wrote:
Hmmm. Assuming the previous version of the package (without the
extensions/updates) avoids all of the testing errors, I would say that
RAW ("rules as written") the only constraint I can see on submitting a
"rollback" version of the package would be the C
I can imagine a (perhaps overly complicated) scenario:
* version 1 passes tests OK when it is submitted to CRAN
* version 2 passes tests OK when it is submitted to CRAN
* CRAN introduces new tests (compiler versions, etc. etc.) that break
version 2 but not version 1.
Now version 1 would still pa
Dear package maintainers,
Dear users of packages `bit`, `bit64`, `ff`,
Everyone interested in sustainable sorting algorithms,
I submitted updated versions for the upcoming R 4.5.0. The are only
minor changes (see the NEWS files) but there is one important change in
bit64:
o setting opti
Hmmm. Assuming the previous version of the package (without the
extensions/updates) avoids all of the testing errors, I would say that
RAW ("rules as written") the only constraint I can see on submitting a
"rollback" version of the package would be the CRAN request for
updates “no more than every 1
Hello all,
Recently I submitted a large update to the package I maintain and was unable to
resolve the testing errors prior to it being archived. I've been unable to
reproduce the errors, so I expect to have to setup my own fedora_clang virtual
machine to debug my package. Ideally I'd want a pr
