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/ > 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? > 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