Is there any downside to reducing the required R version on a published package?
Some users have asked why I required R ≥ 3.4.1 on two recently published packages (e.g. this issue on GitHub). To be honest, I didn't give much thought to the R version when I wrote the packages – devtools::create() set up DESCRIPTION with the version I was using, and the advice in R packages to ‘play it safe and require a version greater than or equal to the version you’re currently using’ made sense to me. However, it seems that this is a barrier for some people to use the packages in environments where they don't have control over the installation, such as university computer labs.
I'd appreciate your thoughts on these questions:
As a general policy, is it better to try to support older versions as much as possible to maximise the audience that can use the package, or to keep up with the latest R version?
Assuming that a package works on R ≥ 3.1, is there anything to lose by reducing the version requirement?
Would CRAN have any problems accepting an update that reduced the required R version?
If your package works on R ≥ 3.1, then I would definitely declare that in DESCRIPTION. It's more accurate than saying nothing and it's better than R ≥ 3.4.1 re: usage by people who don't control their R installation.
FWIW ≥ 3.1 is a nominal goal for the tidyverse packages. However, it is not yet universally true.
No, I don't think CRAN has a problem with lowering the required R version. You should still do your own due diligence.
Here's an example of a travis config file that would help you verify if your package works on R ≥ 3.1:
As a general policy, is it better to try to support older versions as much as possible to maximise the audience that can use the package, or to keep up with the latest R version?
@wilkox I think it's a good idea to try to support at least recent older versions of R. R users are a diverse group, and not every R user aggressively updates their R installation. My R installation evens differs across my various machines. I update immediately on Ubuntu because the package manager (apt) facilitates the transition. On the other hand, I am still running R 3.3.2 on my macOS machine because the transition is more work (and I use that machine less often). You want a potential user of your package to be able to try out your package with minimal activation energy.
Assuming that a package works on R ≥ 3.1, is there anything to lose by reducing the version requirement?
One constraint of supporting older versions of R is refraining from using functions that have been added more recently (e.g. dir.create was added in R 3.2.0). Though one way to get around this is to add the package backports as a dependency.
Another issue with supporting older versions of R is that continuous integration can be more difficult as support packages may fail. For example, devtools was having trouble on R 3.1 (this seems to have been fixed recently; also evidenced by the very useful travis.yml file provided above by @jennybryan), and still doesn't work for R 3.0.3 as far as I can tell.