- 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.