Default to Bioc devel for R-devel

[lshep]

Currently BiocManager would not work with the devel version of R. While the current Bioc works with 4.2 for release and devel, shouldn't BiocManager default to the current Bioc devel so that users would still be able to use BiocManager and Bioconductor packages for a version of R-devel. At the very least when forcing version?

> library(BiocManager)
Bioconductor does not yet build and check packages for R version 4.3; see
  https://bioconductor.org/install

> BiocManager::install(version="3.16")
Error: Bioconductor does not yet build and check packages for R version 4.3; see
  https://bioconductor.org/install

[LiNk-NY]

Hi Lori,

R-devel diverges from R release 4.2 especially when CRAN adds major changes after the release. We don't expect this "future" version of R to work with Bioconductor packages built with R 4.2.

> tail(BiocManager:::.version_map(), 4)
   Bioc   R  BiocStatus RSPM MRAN
34 3.14 4.1 out-of-date <NA> <NA>
35 3.15 4.2     release <NA> <NA>
36 3.16 4.2       devel <NA> <NA>
37 3.16 4.3      future <NA> <NA>

The alternative is to switch Bioc-devel to always run on R-devel. Any thoughts @mtmorgan ?

Best, Marcel

[lshep]

For arguments sake, if I'm developing and I know it will take me longer than this release schedule and developing in prep for next years spring release with R4.3 (R-devel) that means that I can't do anything with Bioconductor then until after the fall release unless I painful manually install every package with a R CMD INSTALL (In proper order for any package dependency list) -- and yes arguably packages right now aren't meant to run on devel but they will come fall release when we branch anyways --

[mtmorgan]

@hpages is the strongest proponent of this approach, which I agree with but don't have any formal influence over.

The flip side of Lori's argument is the person using R-devel and encountering problems with Bioconductor packages that have not been tested on that platform. They, and the package developer, then spend a lot of time debugging something that may not be relevant. Even if they plan to submit in the next release cycle, they'll still have six months to work through issues that require fixing (in the future Bioc devel branch).

FWIW, R-devel has

> tools:::.BioC_version_associated_with_R_version()
[1] ‘3.15’

so using standard R installation instructions

setRepositories() # choose CRAN + BioC repositories
install.packages(<vector of packages to be installed>)

installs the 3.15 version of Bioconductor packages.

[lshep]

@mtmorgan How does the .BioC_version_associated_with_R_version get set? Entirely separate issue but wouldn't the better option be 3.16 ?

And thank you for the suggested work around in the meantime

[mtmorgan]

This is set via @vjcitn communicating with CRAN + R-core.

Changing this value changes how R-devel packages are installed and checked. Generally, this change should be communicated as soon as possible after the release. Usually CRAN is also aware of this, and will prompt 'is now the time...' at some point in the release cycle if we have not initiated the change.

Usually CRAN wants the annotation & experiment data repositories properly populated before making this change. It also exposes those Bioconductor packages used by CRAN packages to testing on R-devel, so (a) generally the Bioc devel builds should be in good shape (so that we are not breaking CRAN reverse dependencies of Bioconductor packages, causing work for the CRAN team and for CRAN package maintainers); (b) an important subset of Bioconductor packages to R-devel; usually this has a conservative effect on changes in R-devel -- if a change in base R breaks 10's or 100's of packages, the change will be reassessed and maybe rolled back or re-implemented. It also means that we are alerted when there are breaking changes in R to Bioconductor packages, usually with useful information about how the packages need to be changed to work with both R-devel and the current release of R (because CRAN does not distinguish between R versions when building packages).

[lshep]

good to know. We have not yet branched the annotations so probably once that is done and the devel report looks descent is when we request the switch then?

[LiNk-NY]

I like the idea of having Bioc-devel always run on R-devel and also have the Bioc version match that of R so that maintaining tools:::.BioC_version_associated_with_R_version() should just be getRversion()[,1:2 ]. Of course, that has some significant side effects but at least they're more manageable. Just my 2¢..

[vjcitn]

I don't think it has to be me communicating this to CRAN + R-core. Any core member could send a note to Kurt Hornik to set the process in motion. I am happy to do it but if I am indisposed Lori or Herve or Nitesh or Marcel could contact Kurt. It would be wonderful to have an SOP with activating conditions clearly stated and as programmatic as possible for this crucial bit of cross-community coordination.

[lshep]

I can reach out after Kayla and I branch annotations. I think that is the last step that would need to be done before that happens then.