Kevin, > It does not request users to make R-devel a _requirement_ of their package.
Sadly it does for new packages. New packages submitted to Bioconductor 3.7 are _required_ to have R >= 3.5 dependency, otherwist BiocCheck will result in a warning ( https://github.com/Bioconductor/BiocCheck/blob/be9cd6e36d95f8bf873b52427d2a97fce6fbb9b9/R/checks.R#L23) and warnings aren't allowed for new package submission. > 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. That's the problem: this is true for packages already in Bioconductor, but it's not ture for the new package submissions. Aaron, > Personally, I haven't found it to be particularly difficult to update R, > or to run R-devel in parallel with R 3.4, even without root privileges. I find it much harder for a normal user to install R-devel (and update it properly, because it's a development version) and running 'devtools::install_github("blabla/my_package")'. > I think many people underappreciate the benefits of moving to the latest > version of R. Don't you think it should be a developer's choice whether to use such new features or ignore them and have a potentially bigger audience? > Enforcing version consistency avoids heartache during release and > debugging. But it's a developer's heartache. As I said, it even can't be attributed to Bioconductor at all, as it's not possible to install the package from bioc-devel, unless you have the corresponding R version. -- Alexey On Mon, Feb 19, 2018 at 6:38 PM, Aaron Lun <a...@wehi.edu.au> wrote: > I'll just throw in my two cents here. > > I think many people underappreciate the benefits of moving to the latest > version of R. If you inspect the R-devel NEWS file, there's a couple of > nice fixes/features that a developer might want to take advantage of: > > - sum() doesn't give NAs upon integer overflow anymore. > - New ...elt(n) and ...length() functions for dealing with ellipses. > - ALTREP support for 1:n sequences (wow!) > - zero length subassignment in a non-zero index fails correctly. > > The previous 3.4.0 release also added support for more DLLs being loaded > at once, which was otherwise causing headaches in workflows. And 3.4.2 > had a bug fix to LAPACK, which did result in a few user-level changes in > some packages like edgeR. So there are considerable differences between > the versions of R, especially if one is a package developer. > > Enforcing version consistency avoids heartache during release and > debugging. There's a choice between users getting annoyed about having > to update R, and then updating R, and everything working as a result; or > everyone (developers/users) wasting some time figuring out whether a bug > in a package is due to the code in the package itself or the version of > R. The brief annoyance in the first option is better than the chronic > grief of the second option, especially given that the solution to the > problem in the second option would be to update R anyway. > > Personally, I haven't found it to be particularly difficult to update R, > or to run R-devel in parallel with R 3.4, even without root privileges. > > -Aaron > > On 19/02/18 14:55, Kevin RUE wrote: > > Hi Alexey, > > > > 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. > > > > Best, > > Kevin > > > > > > On Mon, Feb 19, 2018 at 12:19 PM, Alexey Sergushichev < > alserg...@gmail.com> > > wrote: > > > >> 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 > > > _______________________________________________ > 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