I do agree with you that there is no harm in testing against other version
of R. In a way, that is even good practice, considering that many HPC users
do not always have access to the latest version of R, and that Travis is
making this fairly easy.
Now, with regard to your latest reply, I am wondering whether we're having
confusion here between the "R≥x.x" requirement, and the version(s) of R
that you use to develop/test your package (the version of R installed on
your own machine).
First, I think the "R≥x.x" does not have an explicit rule.
To me, the point of this requirement is to declare the oldest version of R
that the package has been tested/validated for. This does not necessarily
have to be the _next_ version of R (see the core Bioc package S4Vectors:
https://bioconductor.org/packages/release/bioc/html/S4Vectors.html, and I
am sure there are older requirements in other packages).
Here, I think the decision here boils down to how far back in terms of R
versions the developer is willing to support the package. I suppose one
could state R≥2.3 if they're confident about it.
On a separate note, going back to the Bioc guideline that I initially
highlighted ("Package authors should develop against the version of *R* that
will be available to users when the *Bioconductor* devel branch becomes the
*Bioconductor* release branch."), this rather refers to the forward-looking
guideline that the cutting-edge version of any R package should be
compatible with the cutting edge version of R, and that developers should
be working with R-devel to ensure this.
In other words, this only refers to the version of R that the developer
should have installed on their own machine. It does not request users to
make R-devel a _requirement_ of their package.
I hope this addresses your question better, and I am curious to hear if
anyone else has an opinion or precisions to weigh in on this topic.
On Mon, Feb 19, 2018 at 12:19 PM, Alexey Sergushichev <alserg...@gmail.com>
> Hello Kevin,
> Well, bioc-devel packages are tested against bioc-devel (and R-3.5) in any
> case. What I'm saying is that aside from testing the package against
> bioc-devel, I can as well test against bioc-release too on my own. If the
> package doesn't work with bioc-devel it shouldn't pass bioc-devel checks,
> if the package is properly developed and has a good test coverage. So I see
> no problem in allowing developers to test against other versions, on top of
> developing against bioc-devel. And as it's only possible to install the
> package from github and not from Bioconductor, the developer alone is
> responsible for the package to work properly.
> I can't really see a scenario, where requiring R >= 3.5 helps to improve
> the package quality.
> > A short-term workaround can be to create a git branch (e.g. "3.4").
> That's the way I'm doing too, but supporting two branches different only
> in R version looks ridiculous and unnecessary.
> On Mon, Feb 19, 2018 at 12:48 PM, Kevin RUE <kevinru...@gmail.com> wrote:
>> Dear Alexey,
>> The reason is somewhat implicitly given at https://www.bioconductor.or
>> g/developers/how-to/useDevel/ :
>> "Package authors should develop against the version of *R* that will be
>> available to users when the *Bioconductor* devel branch becomes the
>> *Bioconductor* release branch."
>> In other words, developing against the _next_ version of R ensures that
>> all packages in development are tested in the environment where they will
>> be released to the general community. In particular, that environment
>> includes the latest devel version of all Bioconductor packages, that will
>> become their next release version.
>> If developers were allowed to develop and test their package in the
>> _current_ version of R, there is no guarantee that those packages would
>> still work when they are made available with the _next_ version of R (e.g.
>> if one of their dependencies is about to introduce some breaking changes).
>> That could cause all sorts of trouble in the first builds on the next
>> Bioconductor release, which is meant to be a place storing stable working
>> Overall, you will do yourself and your users a favor developing with the
>> _next_ version of R, as this is a forward-looking strategy, as explained
>> above. In contrast, the short-term benefit of developing with the _current_
>> version of R is largely outweighed by the risk of wasting time looking at
>> code that is about to be deprecated.
>> A short-term workaround can be to create a git branch (e.g. "3.4"), where
>> the R version requirement is downgraded. Then, you can always keep
>> developing against R-devel on your master branch and back-port the more
>> recent commit to the "3.4" branch by typing "git rebase master 3.4" in your
>> A recent example of this situation can be found in the discussion here as
>> a branch to the original repository https://github.com/csoneson/iS
>> EE/pull/124 and here as a fork https://github.com/mdshw5
>> I hope this helps.
>> Best wishes,
>> On Mon, Feb 19, 2018 at 8:02 AM, Alexey Sergushichev <alserg...@gmail.com
>> > wrote:
>>> Dear Bioconducotr community,
>>> I wonder, what is the reason behind requirement for dependency R >= 3.5
>>> (currently) for new packages?
>>> As a developer I really want an installation of my package to be as easy
>>> possible and want my package to be easily installed from github. So
>>> currently, when I develop a package I put a R >= 3.4 in my DESCRIPTION
>>> test it using Travis against bioc-release. Then, before submission
>>> to Bioconductor, I have to change R >= 3.4 dependency to R >= 3.5, so
>>> the package passes BiocCheck. However, most users don't have R-devel
>>> installed, so they have R 3.4 in the best case, and for these users I
>>> create another repository branch with R >= 3.4 dependency.
>>> Overall, it is quite bothersome and it doesn't really make sense to me to
>>> to restrict potential users in this way. Am I the only one who have
>>> with this? Am I missing something? Or may be this check could be removed?
>>> Alexey Sergushichev
>>> [[alternative HTML version deleted]]
>>> Biocemail@example.com mailing list
[[alternative HTML version deleted]]
Biocfirstname.lastname@example.org mailing list