Dear Alexey, The reason is somewhat implicitly given at https://www.bioconductor.org/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/iSEE/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]] > > _______________________________________________ > Biocemail@example.com mailing list > https://stat.ethz.ch/mailman/listinfo/bioc-devel > [[alternative HTML version deleted]] _______________________________________________ Biocfirstname.lastname@example.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel