R Version Management - Introduction

The management of multiple R versions seems trivial in the first place but might turn out to be more complex than initially anticipated. Various questions might arise around R version mangement such as:

We’ll address these questions in the following and outline our perspective on them. Note that all of these are suggestions only and “best practices”, in the end the selection of the R version, and their management throughout a project lifecycle, is your own decision!

R Version Selection For New Projects

Our recommendation for new projects is the “latest LTS” version, i.e., the last patch release of the second last minor release. For example, if the latest available R version is 4.2.1, the respective “LTS” would be 4.1.3.

The semantic versioning scheme applied to R version 4.2.1 would mean

  • 4 -> “major” version
  • 2 -> “minor” version
  • 1 -> “patch” version

The following considerations went into this recommendation:

  • Staying with a certain minor release throughout a project lifetime helps to avoid upgrade issues between R minor versions and allows working with one R user library (as R user libraries are versioned on the minor level)
  • The most recent R minor version might not have seen a patch update yet, i.e., it has the X.Y.0 version scheme and might contain uncaught bugs
  • The “LTS” is never older than one year as the R-core release cycle is one year
  • When collaborating with others on projects outside of Posit Workbench, it is likely that these also have the latest “LTS” on their machines. This does often not apply to the most recent R release.

The default R version in Workbench installations configured by cynkra is always the most recent “LTS” version as described above.

Differences Between R Versions On The Patch Level

R versions that differ on the patch level, e.g. 4.1.0 <-> 4.1.1 <-> 4.1.2, do usally not differ with respect to features. Their main differences are on the stability side, i.e., the higher the patch version, the more small issues got fixed along the way.

This is why it is usually good to run on the latest patch version of a minor release as it provides the most robust experience. Each R minor version usually has 3 three to four patch release before the next minor release gets released. The count might differ depending on whether important bug fixes need to be released urgently. For example, the R 4.0 release had up to five patch releases.

Upgrading R Versions

There is no general rule when to upgrade to a newer R version. It depends on your personal philosophy and often on the used R packages in a project. Often R package updates are the final trigger to update the R version as they require a specific minimum version of R to function in the first place.

When running on Posit Workbench configured by cynkra, the motivation to use a newer Package Manager snapshot than the one coupled to the release date of the used R version might be another trigger.

The sole need for a newer Package Manager snapshot must not necessarily come with the upgrade to a new R version. When using {renv} within a project, the package manager snapshot can also be increased individually on the project level without having to bump the R version.

We recommend to go with the “LTS” releases as described above and upgrade R versions in projects once a year.

R Version Management When Collaborating

The simplest solutions is definitely to use a central and shared environment, i.e., a Posit Workbench installation, which comes with multiple preconfigured R versions.

Since this is not always possible, the use of {renv} is highly encouraged as it gives a reference to the R version used in this project. Yet it still requires that all collaborators have exactly this R version installed on their machines. Having multiple R versions installed side-by-side is not always easy and also depends on the operating system. Command line tools like rig or rcli aim to help here.