A traditional software version cycle begins with the development phase, where bugs are expected and ironed out, and ends with the production phase, which promises a seamless user experience.
+
R-releases aims at a space just before production, commonly referred to as QA, in that:
+
+
Each package release has the full endorsement of its own maintainer. R-releases always gives you a version that its developer chose to distribute for general use.
+
The user is still responsible for judging whether a package is appropriate to use. This judgement may require more than a novice understanding of testing, versions, and package compatibility.
+
+
+
+
Continuous maintainer-driven deployment
+
Each package only needs to be registered once. Every new release automatically deploys to https://r-releases.r-universe.dev without needing to go through R-releases again. In other words, the package maintainer is in complete control. This painless maintainer-driven experience was made possible by the incredible infrastructure of rOpenSci’s R-universe system and key insights from Jeroen Ooms.
+
+
+
What about my personal R-universe?
+
You can still maintain a separate R-universe for yourself or your organization. This can continue to hold either release or development versions for yourself and your colleagues. At the same time, R-releases deploys the latest package releases directly to the wider community.
The code of conduct governs all forms of participation in the R-releases project, including package contributions, issues, discussions, and the development of infrastructure. Administrators, moderators, and contributors are all subject to its terms.
+
+
How to register your package with R-releases
+
The one-time registration process proceeds as follows:
+
+
Ensure that the package source code exists in a public GitHub or GitLab repository with the DESCRIPTION file at the root of the project. Example: https://github.com/r-lib/gh.
The overwhelming majority of text files in (3) will be in simple URL format, which has has 3 requirements:
+
+
The name of the file is the package name.
+
The file contains a single line with the package URL. The URL must be authentic and genuine. It must be the true GitHub/GitLab location of the package according to its owners, or an active mirror of the true location.
+
The file ends with a newline character. (A terminating newline is included automatically if you create the file using the GitHub web interface.)
+
+
In rare cases, the package may be in a subdirectory of a GitHub repo, in which case the contents of your text file may be a JSON list with fields package, url, subdir, and branch, and the branch field must be "*release". Example:
To add a dynamic ‘R-releases’ badge for package readme files, like the one above, copy the following markdown snippet, replacing ‘pkgNAME’ with the actual package name in both places it appears:
To edit or remove one or more packages, submit a pull request to edit the files in the packages folder. To protect the package ecosystem, these kinds of pull requests are always flagged for manual review and never automatically merged.
+
+
+
How pull requests are reviewed
+
An automated process periodically scans each new pull request to https://github.com/r-releases/contributions. Depending on the results of the automated checks, the bot automatically merges the pull request, closes it, or flags it for manual review. In the latter case, an R-releases moderator will manually review your pull request and contact you if there are questions. For more information on the manual review process and when it gets triggered, please visit https://github.com/r-releases/help/blob/main/review.md
As the contributors page explains, updates to the R-releases package listings come from pull requests to https://github.com/r-releases/contributions from members of the R community. In the vast majority of cases, a GitHub app automatically merges the pull request. However, some pull requests need to be manually reviewed by an R-releases moderator. This document describes this manual review process. The goals are to:
+
+
Ensure that all pull requests are reviewed using a consistent set of standards and principles that do not vary according to moderator.
+
Ensure these standards and principles are clear and transparent for the R community.
+
+
+
The automated review process
+
The review_pull_requests.yamlGitHub Actions workflow runs periodically and reviews each new open pull request using r.releases.utils::review_pull_request(). Depending on the results of the automated checks, the bot will automatically merge the pull request, close it, or flag it for manual review. The bot will post an informative comment explaining the decision, and it may add a GitHub label to the pull request for triage purposes.
+
The pull request is automatically closed if:
+
+
It attempts to add/modify/delete a file outside the packages folder.
+
It attempts to add/modify/delete a file in a subdirectory of the packages folder.
+
+
The pull request is automatically flagged for manual review if:
+
+
It attempts to modify or delete any existing file in packages.
+
A contributed text file is not a single-line file.
The URL does not exist or is not online at the time it is checked (HTTP error trying to access it).
+
A release could not be found at the repo in the URL.
+
The version-controlled repository name in the URL is different from the name of the file. (For example, if the file is named gh as the package, then the URL https://github.com/r-lib/gh-package would be flagged for manual review, but https://github.com/r-lib/gh would not.)
+
The repository is part of the CRAN mirror at https://github.com/cran. (A fundamental goal of R-releases is to serve complete package dependency chains without reliance on third-party repositories as far as possible.)
+
The package is also on CRAN, and the URL in the pull request cannot be found in the DESCRIPTION file of the latest CRAN release.
+
+
+
+
The manual review process
+
If a pull request is flagged for manual review, an R-releases moderator will read the pull request and ask questions if necessary. Although the moderator may make optional suggestions on a case-by-case basis, package reviews must be consistent, reliable, and inclusive whenever possible. The decision to close or merge the pull request must be based exclusively on the following pre-defined list of requirements:
+
+
Each contribution must comply with the code of conduct. Examples of prohibited content include profanity, malicious behavior, security risks, copyright violations, and other conduct which could reasonably be considered inappropriate in a professional setting. All this applies to the package, the URL, any other metadata in the contribution, and the contents of the package itself.
+
Each contributed URL must point to an existing GitHub or GitLab repository.
+
Each text file must apply to only one package.
+
The text file name must be the name of the package.
+
For JSON listings, the "branch" field must be "*release" (except in specific predetermined cases such as packages in https://github.com/cran), the "subdirectory" field must be supplied and exist, the "url" field must exist and be correct, and the "package" field must agree with the name of the text file.
+
The package name, URL, and all other metadata must be complete and correct.
+
The URL must be the true/official location of the source code or a faithful mirror of the true location. The package maintainers have the authority to choose the URL. Unofficial or unsupported forks should not be included. The moderator must use discretion on a case-by-case basis because sometimes a fork becomes the true version (e.g. if the original maintainer abandons a package and becomes unreachable indefinitely).
+
The URL must have a release on GitHub or GitLab so R-universe can process the package without error. As a last resort, if the maintainer does not provide their own releases, a repository from the CRAN mirror at https://github.com/cran may be registered.
+
If the listing of an existing package is modified, then the moderator must verify that the new information is complete and correct. In many cases, it may be necessary to obtain permission from the package maintainer.
+
The reasons for deleting a package listing may vary on a case-by-case basis, the moderator must carefully consider the impact that deletion would have on the community and on reverse dependencies. In many cases, it may be necessary to obtain permission from the package maintainer.
