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.
--
Alexey
On Mon, Feb 19, 2018 at 12:48 PM, Kevin RUE <kevinrue67 at 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
code.
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
shell.
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
/iSEE/commit/6fb98192a635a6222491b66fb0474dc38f922495
I hope this helps.
Best wishes,
Kevin
On Mon, Feb 19, 2018 at 8:02 AM, Alexey Sergushichev <alsergbox at 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?
Best,
Alexey Sergushichev
[[alternative HTML version deleted]]