search

ropensci / RNeXML

Implementing semantically rich NeXML I/O in R
https://docs.ropensci.org/RNeXML
Other
13 stars 9 forks source link

Many fewer versions of R are tested than compatibility is claimed for #170

Closed hlapp closed 5 years ago

hlapp commented 5 years ago

The DESCRIPTION says the package requires R >= 3.0.0., but only the latest release (of released versions of R since 3.0.x) is tested. Shouldn't this be tested against a matrix of 3.0, 3.1, 3.2, 3.3., 3.4, and 3.5?

Or alternatively, require a correspondingly later version of R?

I'm about to update the Travis tests for Rphenoscape and am wondering about recommended practice between dependency and what actually gets tested.

cboettig commented 5 years ago

Good question. I see your point but I think common practice holds that it would be impolite to use Travis quite so extensively. After all, things are most likely to break on later versions, not on versions where it previously worked.

Also, computing backwards dependencies gets quite tricky, e.g. there's no guarantee that more recent versions of package dependencies of RNeXML (e.g. dplyr) will not increase their own version of R to something more recent than what is required strictly by RNeXML's own base R functions. Thus testing on the earliest version may no longer be possible in the usual travis sense. (Of course one can install older versions of the dependencies, like we do using MRAN in the Rocker tagged versions, but that's a different context).

hlapp commented 5 years ago

I think common practice holds that it would be impolite to use Travis quite so extensively.

I don't know. Travis certainly makes it quite easy by design to test on multiple versions, so it seems a little weird to assume that a capability that's clearly not accidental, and clearly designed for ease of use, should rather not be used. And I know that at least for JavaScript packages it is very common.

I think the burden is more on the code developers - if you have a long running test suite, do you really want to wait N times longer for each pull request due to testing on N versions of the language.

After all, things are most likely to break on later versions, not on versions where it previously worked

Perhaps. At least maybe while you stay within in the same major version.

hlapp commented 5 years ago

I guess I'll close this - it served its purpose at least for me 😀