> It _is_ the developer's choice. But a developer of packages for the Bioconductor > project commits to using R-devel during certain pre-release phases, depending > on proximity in time to a point release of R. (See http://bioconductor.org/developers/how-to/useDevel/) > for full details.) BiocCheck verifies that this commitment is met.
No, BiocCheck doesn't verify this, it just checks for presence of dependence on R >= 3.5. It actually doesn't check, whether I have installed it on my computer at all; or how often I'm updating R-devel and test my package against it; or whether I do some manual tests, as unit tests are running regularly by BioConductor automatically. -- Alexey On Mon, Feb 19, 2018 at 9:03 PM, Vincent Carey <st...@channing.harvard.edu> wrote: > > > On Mon, Feb 19, 2018 at 11:27 AM, Alexey Sergushichev <alserg...@gmail.com > > wrote: > >> 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/be9cd6e36d95f >> 8bf873b52427d2a97fce6fbb9b9/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? >> > > It _is_ the developer's choice. But a developer of packages for the > Bioconductor > project commits to using R-devel during certain pre-release phases, > depending > on proximity in time to a point release of R. (See > http://bioconductor.org/developers/how-to/useDevel/) > for full details.) BiocCheck verifies that this commitment is met. > > >> >> > 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 >> > > [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel