[Bioc-devel] Important Bioconductor Release Deadlines

Fri Apr 5 12:51:22 CEST 2024

On Fri, Apr 5, 2024 at 12:56 AM Anatoly Sorokin <lptolik using gmail.com> wrote:
>
> Dear Levi,
>
> minor correction: not requiring but working with. Testing against r-devel
> and requiring it for development are two different things. If the
> development and maintenance of the Bioconductor package would be my only
> responsibility, I wouldn't argue. But because this is a voluntary activity
> additional restrictions such as maintaining unstable software release,
> which is not needed at all, make it less attractive.
>
> In my mind, the requirements mean that the software is not backwards
> compatible any more. In my experience, cases when packages are not working
> with an R older in major release is rare (for example at the moment all my
> code working with R 3.6, due to limitations on some collaborator's
> systems). I haven't checked but it would be really interesting to run R Cmd
> check on 3.19 packages with R 4.0 and find how many of them will fail.
>
> When we were deciding how to release our code Bioconductor was chosen due
> to its stability and user-friendliness in package and dependencies
> installation, which is crucial for the adoption of the analysis approach by
> biologists who are not so familiar with coding. Forcing them to completely
> reinstall the framework is not so convenient.
>
> But anyway it is just my thoughts.
>
> On Fri, Apr 5, 2024 at 12: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.
> >
>
> But the recent release of 3.19 version of GO.db package forced me to the
> last-minute bug fixing of the code, which was perfectly fine, anyway.
>
> >
> > 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.
> >
>
> That's why each package should contain a reliable set of tests. And again,
> regular updates of the R are fine for the self-managed machines and skilful
> users. Don't fix something, which works!
>
> >
> > 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?
> >
> My point is that too-tight ties make Bioconductor less reliable. When you
> test your code against someone's unstable release you are wasting your
> time, since you have to debug not only your code but the unstable version
> of the platform. I did not sign up as an R beta tester.

Hi Anatoly, sorry to hear about your issue, and I would like to understand more
about the specific technical problem you've encountered.  Maybe we can take
that off line to the developer forum channel in our slack.

On not signing up "as an R beta tester", it may be worth thinking about the
following:  One of the values of participating in an open source community as a
user is the opportunity afforded to "give back" to the many projects
that underlie
any reasonably complex open source tool of interest.  Since the
inception of Bioconductor, I
would say, it is realized that the project is wholly dependent not just upon R
as a language at any given time, but on the evolution of R and CRAN.  Ideas
from Bioconductor such as "vignettes" as package components and testing
resources were brought into R _from Bioconductor_.  R proved adaptable to
the interests of genomic data scientists, who needed vignettes
urgently around the
turn of the century.  Vignettes proved to be very generally valuable, of course,
but their role in packaging started with bioc.  R core members take advantage
of Bioconductor packages to enhance exploration of the surface of
potential language
problems, and "testing against Bioconductor" is a routine part of
several projects.

We have put a lot of effort into achieving approximate "backward
compatibility" and
insulating users from adverse effects of change, but I don't think this has been
summarized effectively to date.  There's also a lot of effort spent on
portability and
convenience -- note the work on supporting ARM linux, which involved work within
and outside the project (thanks Martin Grigorov!) and check out bioc2u (thanks
Dirk Eddelbuetttel and Inaki Ucar!) for zero-configuration installation in
debian-compatible systems.  There are many other folks in the R/CRAN community
helping bioc at user-invisible levels.

I appreciate your effort in communicating the limitation you've encountered and
hope it can be resolved without too much pain.  If there are changes we can make
within the basic framework of R-bioc symbiosis that I've tried to
sketch, let's try
to articulate them.

Best wishes
Vince Carey
>
> Cheers,
> Anatoly
>
> ------------------------------
> > *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

-- 
The information in this email is intended only for the p...{{dropped:12}}