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 <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 > 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 <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 >> 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]] >> >> _______________________________________________ >> Bioc-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/bioc-devel >> > > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel