CRAN Repository Policy

Version $Revision: 3337 $
CRAN Repository Maintainers

Next: , Previous: , Up: (dir)  


Next: , Previous: , Up: Top  


This document describes the policies in place for the R package repository hosted by the Comprehensive R Archive Network. In what follows, this CRAN package repository will be referred to as “CRAN”.

CRAN is maintained by the efforts of volunteers (the “CRAN team”) and the resources of the R Foundation and the employers of those volunteers (WU Wien, TU Dortmund, U Oxford, AT&T Research). Having a package distributed by CRAN is subject to a set of policies, and submitting a package (including an update) to CRAN indicates agreement to these policies.

Distributing code or documentation is subject to legal requirements, and CRAN operates in many jurisdictions. One of the aims of these policies is to ensure that the distributors meet their legal obligations of diligence without excessive work.

The time of the volunteers is CRAN’s most precious resource, and they reserve the right to remove or modify packages on CRAN without notice or explanation (although notification will usually be given).

Next: , Previous: , Up: Top  

Source packages

Next: , Previous: , Up: Top  

Binary packages

Policies for when a (Windows or OS X) binary package will be distributed:

Binary packages are not accepted from maintainers: CRAN will only host binary packages prepared by those responsible for the binary areas. Their packages are made automatically by batch jobs and can take a day or two to appear on the CRAN master site (maybe longer to reach CRAN mirrors).

Binary packages are built for the current version of R: they may also be built for the last version in the previous series (e.g. R 3.1.3 when R 3.2.x is current) or for R-devel.

Questions about binary packages should be addressed to those responsible for building them: Simon Urbanek (OS X) and Uwe Ligges (Windows); email addresses ‘’.

Next: , Previous: , Up: Top  


When submitting a package to CRAN you should use the submission form at (and not send an email). You will be sent a confirmation email which needs to be accepted.

If this fails, upload by anonymous ftp to and send a (plain text ASCII) email at the same time, with subject line as specified below.

In either case, you can check that the submission was received by looking at Submission difficulties (such as non-receipt of the confirmation email) can be discussed with

In more detail:

Previous: , Up: Top  


Re-submission is done in the same way as submission, using the ‘Optional comment’ field on the webform (and not a separate email) to explain how the feedback on previous submission(s) has been addressed.

Updates to already-published packages must have an increased version number unless a ‘same-version update’ is requested by the maintainers. Increasing the version number at each submission reduces confusion so is preferred even when a previous submission was not accepted.