Backwards compatability


I tried running some code again this morning I haven’t used in a couple of months (it worked at the end of March when RECAP met with Paul in Leicester)

 R> devtools::install_github("datashield/dsBetaTestClient")                                                                                                                                                                                                                                                                    
 Downloading GitHub repo datashield/dsBetaTestClient@master
 from URL
 Installing dsBetaTestClient
 '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save --no-restore --quiet CMD INSTALL  \
 '/tmp/RtmpaU4XTV/devtools56e259a65b96/datashield-dsBetaTestClient-e133e5d' --library='/home/user/R/x86_64-pc-linux-gnu-library/3.3' --install-tests
 ERROR: this R is version 3.3.3, package 'dsBetaTestClient' requires R  >= 3.4.0
  * removing ‘/home/user/R/x86_64-pc-linux-gnu-library/3.3/dsBetaTestClient’
 Installation failed: Command failed (1)

I’m using R on Debian stable. I know that Debian is or will shortly be frozen in preparation for the next release, but I do think it is good where possible to maintain backwards compatibility. I guess this is related to Stuart’s question last month?



Hi, I added a “Depends: R (>= 3.4.0)” to the DESCRIPTION to match imported packages of dsBetaTestClient. (I just noticed that “metafor” required R 3.5.0)

Do we have an other problems with specifying an older version of R in “Depends”?


Hi Andrei,

I agree this is a pain, and I also spent a couple of hours swearing at it this week. The root cause of this is that we haven’t done a proper DataSHIELD release for a long time, and we are relying on people installing from the BetaTest repos source -


this repo contains bleeding edge development of DataSHIELD that is pushing up the required R version numbers. Once we do our big release (move much of dsBetaTest in to the main repos) - aiming for September - I’d expect most people to not have to install from github and this problem should go away.

I’m also hoping to have a policy session at the September workshop where we decide on how we deal with breaking changes like this.

Not very helpful in the short term I admit! One temporary hack might be for you to delete the function which is causing this version bump and manually edit the description file. @swheater - do you think this would work and do you know which function it is?



HI, the ‘metafor’ package is used by the ‘ds.glmSLMA.o’ function. There is an argument to ‘ds.glmSLMA.o’ called ‘combine.with.metafor’ (default TRUE) which if FALSE means that no operations from the ‘metafor’ package are called.

I can think of reason why this could help, but others reasons why it wouldn’t. I am not sure what the practical effects of always specifying FALSE for the argument.


Thanks @swheater and @olly for the responses - and also the suggestion of a temporary work around. I’m looking forward to the workshop in September and completely realise that I am at the cutting edge of your development here. In fact, we will probably be waiting a bit with most of our analyses until after the next release of DS, but I did want to highlight the issue.