Bump R dependency to R 3.2.0 ?

[mattdowle]

What do people think?

R 3.2.0 was April 2015. Current dependency is R 3.1.0 (April 2014). I have quite a low resistance to moving it up as long as we support over 3 years old. And we would still be supporting 4.5 year old R.

The motivation is that PR #3802 doesn't pass on R 3.1.0 (thanks to GLCI letting us know already) due to this difference :

# R 3.1.0
> jsub = quote(list(A=mean(x), B=y+2))
> names(jsub)
[1] ""  "A" "B"
> names(jsub) = NULL
> names(jsub)
[1] ""  "A" "B"

# R >= 3.2.0 
> jsub = quote(list(A=mean(x), B=y+2))
> names(jsub)
[1] ""  "A" "B"
> names(jsub) = NULL
> names(jsub)
NULL

Thanks to this new feature in R 3.2.0:

• names(x) <- NULL now clears the names of call and ... objects.

That nice change was at C level in src/main/attrib.c:removeAttrib() here: wch/r-source@3d5a3b0#diff-606a8f9047f5c8e5856a59f32e1e997f

R 3.1.0 could be supported using the same copy as was done before the PR. The copy is of an expression so it's not the speed or memory that concerns me, just the extra/inelegant code (it wasn't just a copy but a conversion of jsub though as.list.default, and then a construction of the call again afterwards using call()). I haven't looked too hard at a possible workaround yet. It took me a while to debug it, and I've just got to this stage, so I thought I'd first float the idea of bumping the dependency to R 3.2.0.

[MichaelChirico]

I'm on vacation so may not be able to dig deeper, but a few things that would help:

• how many places are there in the code where we comment about 3.1.0/3.2.0? wondering if this is the only thing that would be bumped (I seem to recall a few other workarounds we've done)

• does CRAN/anything else offer any objective numbers on users of <3.2.0 left? e.g. download logs. will miss anyone with an old version sitting on a machine but could catch e.g. docker images pointing to these.

personally I'd be in favor of bumping but having a couple more data points to balance a bit more objectively would be helpful to record

[jangorecki]

For me it does not sound to be reason good enough to cut off potential environments that might be still on R 3.1. Usually the most critical environments are the ones that are more difficult to upgrade. CRAN stats are likely to not give much information usage of those, as they might not be even contacting CRAN at all.

[HughParsonage]

Question: are there actually systems that cannot upgrade R but can upgrade data.table?

[jangorecki]

@HughParsonage looking at maintenance effort related to upgrade I think it is quite common scenario. When you upgrade R you have to reinstall all pkgs, and on production you need to reinstall them in the same version they were before, which adds complexity. Upgrading single package, that doesn't have any dependencies is so much easier. You only take care of your code and packages that imports data.table. To confirm they are compatible with recent version.
AFAIR... I was once on an job interview in biggest cloud/hosting provider company. To solve a problem they gave me a machine having 3.0.1 at the time 3.4.4 was already there. I was able to upgrade data.table package but not R (due machine configuration). I was able to update data.table to 1.8.x only because of R version.

Addressing your question precisely. I think it is uncommon in well maintained R environment, but unfortunately I think that not well maintained R environments are much more common.