[R-pkg-devel] CRAN modifications of packages

Max Kuhn mxkuhn @end|ng |rom gm@||@com
Fri May 3 17:55:34 CEST 2019

I've noticed a trend in the last year of a CRAN maintainer making
modifications to packages without notification to the package authors or
the community. Some times these have been made during a submission [1]
and,  in other cases, for existing packages [2]. In the latter case, we
intuit  that there are some cases where the maintainers have not responded
to  communications about required changes to existing versions.

In some cases, the changes are minor (see rngtools example linked below)
but also come with a strict R version dependency on the *current* version.
This causes a considerable number of problems for these packages and their
reverse dependencies. Since the reasons for the changes are not public, it
is unclear why they could not have been considerably less invasive.   The
process of making these changes is in direct opposition to the CRAN
policies, such as

> If for some reason the submission has to be made by someone else (for
example, a co-author) this needs to be explained, and the designated
maintainer will need to confirm the submission.

> If an update will change the package’s API and hence affect packages
depending on it, it is expected that you will contact the maintainers of
affected packages and suggest changes, and give them time (at least 2
weeks, ideally more) to prepare updates before submitting your updated

It is understandable that the CRAN maintainers require package maintainers
to check reverse dependencies. There doesn't appear to be a good reason
that CRAN maintainers do not follow these rules.

In the case where a package maintainer has not properly responded to a
substantive issue, it is unclear what should happen. This does put CRAN in
a bad position, but one would hope that minimally invasive changes be made
and that the impact on the reverse dependencies be measured and processed
like a normal CRAN submission.  In particular, the effect of making
quadprog >= 3.6.0 has been significant due to failures to install  reverse

Perhaps some minimal changes to the process could be:

1. There should be some sort of visible status (analogous to ORPHANED)
that clearly indicates this has happened, so users can better understand
the context of the change. An update to any NEWS file would also be

2. CRAN should, at least temporarily, be listed as an author.

3. Reverse dependency authors who are affected are notified a priori.

Has anyone else experienced similar situations and how did you deal with
the consequences of the changes?


[1] https://github.com/gdkrmr/dimRed/issues/27#issuecomment-437458488





	[[alternative HTML version deleted]]

More information about the R-package-devel mailing list