[Bioc-devel] Important Bioconductor Release Deadlines

[Henrik Bengtsson]

> 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.research using 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-bounces using r-project.org> on behalf of Anatoly Sorokin <lptolik using gmail.com>
> Sent: Thursday, April 4, 2024 10:28:47 PM
> To: Kern, Lori <Lori.Shepherd using roswellpark.org>
> Cc: bioc-devel using r-project.org <bioc-devel using 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 using 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 using r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> Bioc-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel