The reason is somewhat implicitly given at
"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/iSEE/pull/124
and here as a fork
I hope this helps.
On Mon, Feb 19, 2018 at 8:02 AM, Alexey Sergushichev <alserg...@gmail.com>
> 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 as
> 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 and
> 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 that
> 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 issues
> 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