Production repository

The Production repository comprises a subset of Community package releases which are mutually compatible and meet a high standard of quality.

Users

Production deploys in periodic snapshots throughout the year (details below). The current Production snapshot was created on 2024-11-15 when base R had version 4.4.2. All packages passed automated checks at that time. However, the same checks might not pass using a different version of R or different versions of dependencies from CRAN.

For the current snapshot, please use R version 4.4.2 and CRAN dependencies from 2024-11-15 to ensure compatibility. Posit Public Package Manager (p3m) can help. Example:1

install.packages(
  "polars",
  repos = c(
    "https://production.r-multiverse.org",
    "https://packagemanager.posit.co/cran/2024-11-15"
  )
)

Checks

To reach Production, a package release must pass the following R-multiverse checks:

  1. R CMD check must pass (no errors or warnings) on Mac (R-release), Windows (R-release), Linux (R-devel).
  2. The release must not have an active security advisory.
  3. The DESCRIPTION file must not have a Remotes: field.
  4. The current version number must be greater than the version numbers of past releases of the same package.
  5. The release must not strongly depend (Depends:, Imports:, LinkingTo:) on an R-multiverse package with any any of the above issues. 2

Snapshots

Once every 3 months, Production updates all its packages simultaneously and deploys a snapshot. Production does not add, remove, or update packages at any other time. 3 Packages change slowly in Production, but they are mutually compatible. 4

Staging

Rather than pull releases directly from Community, Production draws from an intermediate repository called Staging. The Staging repository is active during the month-long period prior to each snapshot. During that time, Staging stabilizes the Production candidates while still allowing bug fixes.

While Staging is active, if a package is failing one or more R-multiverse checks, then new releases of that package are continuously pulled from Community. Otherwise, Staging freezes the package at its current release and no longer accepts updates from Community. This freeze prevents new problems in reverse dependencies downstream.

At snapshot time, Production creates the snapshot from the subset of package releases in Staging which pass R-multiverse checks. A month after the snapshot, Staging resets (removes all its packages) so that an entirely new set of Community releases can become candidates for Production.

Schedule

Every year, Staging and Production follow a schedule given by the dates below.

Quarter Staging resets Staging becomes active Production snapshot
Q1 December 15 January 15 February 15
Q2 March 15 April 15 May 15
Q3 June 15 July 15 August 15
Q4 September 15 October 15 November 15

Status

R-multiverse has a status system to broadcast the latest R-multiverse check results of each package. In each of Community and Staging, there is an HTML page for every package. Example:

In addition, each package has an RSS feed that updates on each new package release to each repository:5

Debugging

R CMD check errors in Staging may be difficult to diagnose. For example, Staging might have different versions of dependencies than you have on your local machine.

The packages.json file has all the Git commit hashes of all the versions of packages in Staging. If you can identify the specific dependency that is causing problems, you can install the version in Staging and reproduce the issue locally. For example, if packages.json lists a dependency:

  {
    "package": "polars",
    "url": "https://github.com/pola-rs/r-polars",
    "branch": "a76b8d56e6f39a6157880069f9d32f3cc1f574d7"
  },

then you can install the version of that dependency from R:

pak::pkg_install("pola-rs/r-polars@a76b8d56e6f39a6157880069f9d32f3cc1f574d7")

then restart R and run the following to reproduce the issue:

devtools::check("yourPackage")

Alternatively, you can create your own personal universe, give it a strategic subset of dependencies from packages.json, and omit the "branch" field from your package so the checks run on every commit. Visit https://ropensci.org/r-universe/ to learn more about using R-universe directly.

Footnotes

  1. Caveat: when setting two URLs in the repos argument, the same package may be in both repositories, and the highest version is always preferred.↩︎

  2. However, an R-multiverse package can strongly depend a package from CRAN, regardless of CRAN check status, as long as that package remains available on CRAN.↩︎

  3. A package is only removed from a snapshot if it becomes absolutely necessary to do so, e.g. because of an egregious policy violation.↩︎

  4. And compatible with versions of dependencies that were on CRAN at the time of the snapshot.↩︎

  5. except in Staging when Staging is currently inactive.↩︎