My package will be broken on CRAN. When should I submit the fix?

Package development
,
#1

I'm a maintainer of a package on CRAN and it is going to be broken by the breaking changes of upcoming ggplot2 (congratulations for the release, by the way :tada: ).

Now I wonder how to respond to the email sent by revdepcheck:

  1. For each failing check, either update your package, or tell me
    that I have a bug. If you have made changes to your package, please
    submit an update to CRAN before {release_date}.
    https://github.com/r-lib/revdepcheck/blob/a6ea6793c35428c5f99939a9f3afa390ae823c8a/inst/templates/email-broken.txt#L21-L23

This says I should take action before the release of ggplot2 2.3.0. But, I've planned to submit my update after the release. Since I'm rewriting whole my package using a new feature of ggplot2, which is available only after version 2.3.0, it's a bit tiring to make it compatible with both versions... :thinking:

Is it OK to wait until the new version is actually released? Or is it my responsibility to prevent the possible failure so that ggplot2 will be released fluently?

#2

I too am grappling with this one but I've decided to give a go to making it compatible with both versions. A lot of my work has been in environments where it is non-trivial to upgrade R packages so I have a sympathy with people who will want my package to work with an older version of ggplot2 - at least for a year or so. This also gets around the problem of when to do the release (the answer becomes "as soon as possible").

Big caveat is that I haven't yet actually tried and seen how difficult it will be to have it work with both versions of ggplot2...

1 Like
#3

Thanks! Agreed, now I'm gradually making up my mind to respect backward compatibility...

#4

FYI, the errors of your package (ggseas, right?) seems the very same kind of what I face; since the mapping now consists of quosures, not symbols, we should use rlang::quo_text() instead of as.character().

So, maybe it's enough to alias rlang::quo_text() as the as.character() method for quosure...?

as.character.quosure <- rlang::quo_text
1 Like
#5

I believe it would be safer to wrap that in a function:

as.character.quosure <- function(x, ...) rlang::quot_text(x)

Reason is that your construct would capture the rlang::quo_text function at time of installation and places that in the installed package. The consequence of that is that any update to the rlang package won't be reflected in yours. You would still have the old version of rlang::quo_text in the installed package. Hence the version of rlang::quo_text would be dependent upon when the user installed the package. That's why it's better to wrap it in a function. That way you point to whatever version of rlang is installed at the moment you use the function, as opposed to the moment you install the function.

This is similar what you would do when you add a new S3 generic and copy the old one into a fun.default method. For reference: your construct was once suggested in the R extensions manual, but that has since been updated:

https://cran.r-project.org/doc/manuals/R-exts.html#Adding-new-generics

4 Likes
#6

Ah, thanks for pointing out! I often make this kind of mistakes...

#7

Just for the record; this snippet was indeed all that was needed to update ggseas to be ready for ggplot2 2.3, and it does continue to work with ggplot2 2.2 as well. So thanks, this has saved me what I thought would be a much harder struggle with tidyeval.

And noting that it is quo_text not quot_text.

#' @importFrom rlang quo_text
as.character.quosure <- function(x, ...) rlang::quo_text(x)
2 Likes