> Henrik, if Bioconductor releases weren’t tied to R releases, how could > Bioconductor test them? I guess like CRAN where as long as a package says it > depends on R >= 2.0 then you’re free to try installing on 2.0 even though the > combination has never been tested? Maybe I worry too much about such testing > since CRAN seems OK anyways, as far as we know?
TL;DR: I think Bioconductor could say: "We have only tested Bioc release on R version x.y. There is no guarantee it will work with another version of R." Here is my view: The Bioconductor Project guarantees that R packages part of the the Bioc release version and the Bioc development version are well tested and work well together. That is the agreed upon objective. Then there's the objective that Bioconductor wants to protect end-users from shooting themselves in the foot. This is done by preventing users from mix-and-match installing Bioc release and development packages, which is the main role of the BiocManager package. Half of the year, it's easy to implement this protection, because the Bioc release runs on R release and Bioc devel on R devel. I see that as an obvious first approach, because R itself takes care of everything for us and Bioc release and devel are nicely separated on the users computer. This model worked really well when R had two releases per year. However, even since R moved to one release per year and Bioc kept two, the above model cannot be used six months of the year. Instead, for those months, we have to manually manage our own R package library if we would like to swiftly move between Bioc release and Bioc devel versions. I'm pretty sure, few users and developers actually bothers with that. I would like to see a model where you can instantaneously switch between Bioconductor versions for a given R version when you launch R, e.g. BiocManager::use("release"), BiocManager::use("devel"), and BiocManager::use("3.16"). Under the hood, this would just reconfigure .libPaths() and the R 'repos' option. Now, imagine we had the latter in place, how would we look at the dependency between Bioc version and R version? I suspect it's the technical problems that keep us stuck with the above half-broken model rather than what we ideally want. To address "how could Bioconductor test them?": I think this question has two parts to it. The first one is practical/financial. If we had sufficient compute resources, we could of course test Bioc release and Bioc devel on R oldrel, R release, and R devel. Those are the version that CRAN guarantees all CRAN packages support. If a CRAN package fail on one of those, it will be archived on CRAN, unless you clearly state and argue for a give R version requirement. On the other hand, by promising to support multiple R versions, you constrain what new R features an R package might use. So, if Bioconductor wants to make life easy for package developers so that they don't have to worry about backward compatibility, then Bioconductor might want to be more conservation and say, we only guarantee support for R release and R devel. Which is basically what we have today (or at least half of the year). To address "I guess like CRAN where as long as a package says it depends on R >= 2.0 then you’re free to try installing on 2.0 even though the combination has never been tested?": Yes, CRAN only tests on R oldrel, release, and devel version. Anything beyond that is "Use at your own risk". I think that's perfectly fine. Some package managers test against old versions (e.g. via GitHub Actions) and maintain a "Depends: R (>= 2.0)" specification. There are also lots of packages that are no longer updated and just keep working regardless of new R releases, meaning their code is never changes, meaning if they passed CRAN's checks on R 2.0.0 back in the days, they will still pass those checks. I argue that it adds unnecessary friction to users (and developers) by going extra miles trying to prevent them from running a Bioc devel package on an older version of R just because "Bioconductor hasn't tested it, so we cannot guarantee it works, so we will not allow you to install it". My opinion is that Bioconductor should only use on the built-in "Depends: R (>= x.y)" feature to deal with dependencies and rely on maintainers to keep them up-to-date. But if they don't, it's not a big deal, because the overall expectation should be that the Bioconductor Project only guarantees things to work for a specific R version. I think the biggest difference between Bioconductor and CRAN is the decision how to deal with broken package dependencies. CRAN takes the freedom to kick packages out within two weeks. They don't have to think about maintaining a stable "CRAN release" bundle for six months. In contrast, Bioconductor promises to maintain "Bioc release" for six months. OTH, I don't know how this works in practice. I know broken packages will not make it to the next Bioc release version if they're not fixed, but is there any pressure to fix them if they break the current release version? CRAN relies on peer pressure to get popular packages to be fixed. /Henrik PS. I find this thread and all the comments herein useful and refreshing. I think all have slightly different views on what Bioconductor is, what it provides, and what it should provide. It's health to revisit and recalibrate these things once in a while. On Thu, Apr 4, 2024 at 8:39 PM Levi Waldron <lwaldron.resea...@gmail.com> wrote: > > Anatoly, delaying dependency on R 4.4 until October would mean 6 months of > Bioconductor release requiring an old release of R for users. Bioconductor > developers developing against r-devel means that users get a new Bioconductor > release that works immediately on the new R. And I think a main purpose of a > 6 month devel and release cycle is to provide a comfortable period for > everyone to work out new features and bugs and to resolve downstream > consequences that may arise. Delaying the Bioconductor release by a week or > something might actually encourage a habit of last-week bug fixes that should > be discouraged 😉. I really can’t see any way around requiring developers to > test against r-devel without sacrificing timeliness and reliability for > users. There are also Docker and GitHub Actions options that don’t require > installing r-devel to test against it. > > I think many HPC clusters now support Singularity, which is a more reliable > and easier way to run packages with a compatible version of R. Installing > from GitHub on an old version of R has no guarantees of being tested or > working correctly even if it installs without error, and I see as a sacrifice > of software reliability for convenience that can be avoided with Singularity > or regular R updates. > > Henrik, if Bioconductor releases weren’t tied to R releases, how could > Bioconductor test them? I guess like CRAN where as long as a package says it > depends on R >= 2.0 then you’re free to try installing on 2.0 even though the > combination has never been tested? Maybe I worry too much about such testing > since CRAN seems OK anyways, as far as we know? > ________________________________ > From: Bioc-devel <bioc-devel-boun...@r-project.org> on behalf of Anatoly > Sorokin <lpto...@gmail.com> > Sent: Thursday, April 4, 2024 10:28:47 PM > To: Kern, Lori <lori.sheph...@roswellpark.org> > Cc: bioc-devel@r-project.org <bioc-devel@r-project.org> > Subject: Re: [Bioc-devel] Important Bioconductor Release Deadlines > > Hi all, > > I'm sorry for the complaint, but do you really think it is wise to make the > new release dependent on the R version which has not released yet? > > I have a lot of R-related projects going on apart from maintaining the > Bioconductor package and I'm not comfortable installing the unreleased > version of R on my machine and spending time debugging it in the case of > possible problems. > > At the same time, I have an error, possibly caused by a new version of > GO.db package, which BioNAR is dependent upon and I can not fix it > until the R 4.4 release on the 24th of April when I would have less than a > day to fix the possible problem and fit into R CMD build and R CMD check by > the Friday April 26th. Don't you think this is a rather tight time frame? > > > Sorry once again, for the complaint. > > Cheers, > Anatoly > > On Tue, Mar 26, 2024 at 11:06 PM Kern, Lori via Bioc-devel < > bioc-devel@r-project.org> wrote: > > > Import update: The Bioconductor Release will be May 1 following the > > release of R 4.4 on April 24. > > > > The Bioconductor 3.18 branch will be frozen Monday April 15th. After that > > date, no changes will be permitted ever on that branch. > > > > The deadline for devel Bioconductor 3.19 for packages to pass R CMD build > > and R CMD check is Friday April 26th. While you will still be able to make > > commits past this date, This ensures any changes pushed to > > git.bioconductor.org are reflected in at least one build report before > > the devel branch will be copied to a release 3.19 branch. > > > > Cheers, > > > > > > > > Lori Shepherd - Kern > > > > Bioconductor Core Team > > > > Roswell Park Comprehensive Cancer Center > > > > Department of Biostatistics & Bioinformatics > > > > Elm & Carlton Streets > > > > Buffalo, New York 14263 > > > > > > This email message may contain legally privileged and/or confidential > > information. If you are not the intended recipient(s), or the employee or > > agent responsible for the delivery of this message to the intended > > recipient(s), you are hereby notified that any disclosure, copying, > > distribution, or use of this email message is prohibited. If you have > > received this message in error, please notify the sender immediately by > > e-mail and delete this email message from your computer. Thank you. > > [[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 > > [[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