Conda-forge.github.io: How many versions of R to support at a time?

[jdblischak]

Our current policy has been to support 2 versions of R at the same time, typically the first patch release from both the current minor release and previous minor release (e.g. 3.4.1 and 3.5.1), until supporting the older version becomes too cumbersome (e.g. why we stopped supporting 3.4.1).

We recently built R 3.6.1 for conda-forge. As we starting building R packages for R 3.6.1, should we continue to support R 3.5.1?

cc: @conda-forge/r @conda-forge/core
xref: https://github.com/conda-forge/conda-forge-pinning-feedstock/pull/245, https://github.com/regro/cf-scripts/pull/540, https://github.com/conda-forge/r-base-feedstock/pull/89

[jdblischak]

I personally think we should continue to support R 3.5.1 for as long as it is feasible. This is because it gives conda-forge R users more flexibility. For example, when I start a new project I like to pin the package versions as early as possible to avoid errors introduced by package updates. A project can easily last a year, and I don't want to always have to migrate all my R packages in my conda environment because I need to add an R package that was recently added, and thus only available for the latest release of R.

But some other things we need to consider are:

• CI build time
• maintenance burden
• interoperability with bioconda

[bgruening]

Bioconda only needs to support the latest version of R, this is because Bioconductor only supports the latest version of R. So I think we are fine by 3.6 only.

Afaik older R versions also do not get any security updates once the .3 version is released. So maybe we can build R versions for older R until .3 is released, starting from 3.6 onwards? This means:

• building against 3.6 now, only
• building against 3.7 as soon as it is out
• building against 3.6 until 3.6.3 is out, which is around 3.7.1

[dpryan79]

@bgruening There's no overlap between the versions, so 3.6.3 will be out before 3.7.0

If two releases are supported I suggest putting a time limit on that (e.g., support is dropped by October at the latest) or otherwise trying to come to some kind of understanding regarding how we assess that continued support of an old R version continues to be feasible.

[dbast]

I try to always follow to newest versions of packages to learn as early as possible via CI on every commit, if I am using an unstable/deprecated package/api/function. Additionally also the output of conda env export (which fully pins also libs and packages including build number) and in critical cases even the conda-packed environment is stored.

I am fine with supporting one/two R versions at once and but also like the idea of a time limit, e.g. till October.

[cbrueffer]

I have similar requirements as @jdblischak and would thus like to see two versions supported as well.

How about supporting the earlier build (3.5.1 now) until the next R .0 release (3.7.0), when the date for the next .1 release and thus an r-base update are on the horizon?

[jdblischak]

Afaik older R versions also do not get any security updates once the .3 version is released.

@bgruening I am not concerned about security updates for the older version. Most users are running R for their own personal use (i.e. on their local machine or HPC). Anyone exposing R in production would of course need to upgrade to a more recent version, but that is a different use case than the typical researcher.

Also, I searched the R changelog, which goes back to R 3.0.0, and I could only find one instance each of "security" and "vulnerability".

[jdblischak]

I try to always follow to newest versions of packages to learn as early as possible via CI on every commit, if I am using an unstable/deprecated package/api/function. Additionally also the output of conda env export (which fully pins also libs and packages including build number) and in critical cases even the conda-packed environment is stored.

@dbast I agree that during the active phase of a project it is good practice to use the latest versions. But once a project goes into maintenance mode (i.e. I run conda env export), if I return to it in 6 months, I'd like to be able to add an additional package for the same R version without updating everything.

[dpryan79]

Since there's no strong opposition to supporting two versions for at least some period of time, perhaps we can update the pinnings/start the migration and work out the details of exactly when 3.5.1 support gets dropped afterward.

[jdblischak]

we can update the pinnings/start the migration and work out the details of exactly when 3.5.1 support gets dropped afterward.

@dpryan79 Agreed. I don't know how long it will be feasible to support 3.5.1, but I'd like to at least attempt to support it as long as possible (but of course no later than the 3.7.1 release).

[bgruening]

@bgruening I am not concerned about security updates for the older version. Most users are running R for their own personal use (i.e. on their local machine or HPC). Anyone exposing R in production would of course need to upgrade to a more recent version, but that is a different use case than the typical researcher.

But we are not just building for researchers I hope, but also for production and medical care ... And it is also not only about security but also about general support and bugfixes. We got a lot of push back from Bioconductor for example as we attempted to use a wrong R version. There seems to be a deliberate choice in the R community to not support older releases.

Let's see how it goes this time and when it gets unfeasible to support both versions. I will update the PR now.

[bgruening]

Updated :)