[Bioc-devel] choosing R version dependency for existing packages

Henrik Bengtsson henrik@bengt@@on @ending from gm@il@com
Sat Nov 3 20:48:44 CET 2018


I'm using

    Depends: R (>= 2.12.0)

to communicate that I've tested/verified that the package works as far
back as R 2.12.0.


Also, since R (>= 3.5.1) and R (>= 3.5.0) has been mentioned here, in
'Writing R Extensions' there is:

"It is inadvisable to use a dependence on R with patchlevel (the third
digit) other than zero. Doing so with packages which others depend on
will cause the other packages to become unusable under earlier
versions in the series, and e.g. versions 3.x.1 are widely used
throughout the Northern Hemisphere academic year."

which suggests one should aim for R (>= x.y.0).  This is also tested
by `R CMD check --as-cran` or `_R_CHECK_R_DEPENDS_=warn R CMD check`,
e.g.

* checking package directory ... OK
* checking DESCRIPTION meta-information ... WARNING
Dependence on R version ‘3.5.1’ not with patchlevel 0
* checking top-level files ... OK

The source code comments
(https://github.com/wch/r-source/blob/R-3-5-branch/src/library/tools/R/check.R#L982-L1008)
give more motivation behind this check:

## Dependence on say R >= 3.4.3 when 3.4 is current can
## cause problems with revdeps (and did for 3.2.x).
## We only check recent ones: maybe previous two
## (R-release and R-old-release) while this is R-devel

I believe this is written from the perspective of CRAN and their tests.

/Henrik
On Sat, Nov 3, 2018 at 12:27 PM Paul Shannon
<paul.thurmond.shannon using gmail.com> wrote:
>
> Thanks, Martin.
>
> I have backed off MotifDB’s R requirement to 3.5.0.  I will experiment with removing the requirement entirely in the new devel branch.
>
>  - Paul
>
> > On Nov 3, 2018, at 1:37 AM, Martin Morgan <mtmorgan.bioc using gmail.com> wrote:
> >
> > If users are 'playing by the books' and using BiocManager::install(), the version of R is coupled with the version of Bioconductor / your package, so specifying an R version is irrelevant. In addition, saying your package has a dependency R >=... implies that there will be no breaking changes in some future R, which requires a certain amount of foresight. And using R itself would seem to be a requirement for an R package. So in principle my feeling is that it doesn't make sense to include R or an R version as a dependency.
> >
> > In a more practical setting it might be that your package depends on a specific feature of R, or that you yourself are only confident that a particular version of R will provide the needs of your package. It might then be appropriate to specify that R version. Again in the domain of the ideal, new R features would be introduced in R-devel, with bug fixes only in the point releases. So a dependency like R >= 3.5.0 would seem appropriate.
> >
> > I'm not sure whether these comments are helpful or not... __
> >
> > Martin
> >
> > On 11/2/18, 3:19 PM, "Bioc-devel on behalf of Paul Shannon" <bioc-devel-bounces using r-project.org on behalf of paul.thurmond.shannon using gmail.com> wrote:
> >
> >    A user of MotifDb requests - sensibly, I think - that I loosen the requirement
> >
> >      Depends: R (>= 3.5.1)
> >
> >    which I added before the release.   This seems sensible and supported by, for example, R (>= 2.10) in GenomicRanges.
> >
> >    Is this, then, the heuristic?
> >
> >      - new packages should depend on the lastest release of R
> >
> >      - older existing packages should depend on earlier
> >        versions of R, possibly sticking with the version of R in
> >        which they originally appeared, as long as they have not
> >        been subsequently modified to use new R features.
> >
> >    - Paul
> >
> >
> >
> >
> >
> >
> >
> >    _______________________________________________
> >    Bioc-devel using r-project.org mailing list
> >    https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
> _______________________________________________
> Bioc-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel



More information about the Bioc-devel mailing list