Skip to content

Preparing a new CRAN Release

Rayman edited this page Jun 19, 2016 · 1 revision

This page collects guidelines for preparation of package release.

About merging branches

  • Check all the remote branches and contacted corresponding contributors to see if their work are ready to merge. For those who are not ready to incorporate their work in the next release. It is recommended to rebase (git rebase) their current work after next version of refund is released.

  • Always perform the first round of merges with \devel branch. \master branch should only merged with \devel branch. Therefore, at least two checks (R CMD check) should be performed -- one for newly merged \devel branch and the other for newly merged \master branch.

  • Currently, the unit test is only performed in \devel branch to accelerate the checking process for \master branch. So be careful when rebase the \devel branch with \master branch and make sure the unit test related files are not lost during the merging process.

  • The new updates should be properly documented in NEWS.md in the \master branch.

About checking

  • It is always a good idea to check the package with the latest development version, R-devel. It’s painful to manage multiple R versions, especially since you’ll need to reinstall all the packages. Instead, you can run R CMD check on CRAN’s servers with devtools::build_win(). This builds your package and submits it to the CRAN win-builder. 10-20 minutes after submission, you’ll receive an e-mail telling you the check results.

  • Check the package in different platform. Linux is automatically tested through TravisCI. Windows can be handled by devtools::build_win().

  • You must fix all ERRORs and WARNINGs. A package that contains any errors or warnings will not be accepted by CRAN. I also find NOTEs are also unacceptable in most cases so try to eliminate as many NOTEs as possible. After the checks are done and passed, document cran-comments.md properly in master branch.

  • If you see any ERRORs, WARNINGs and NOTEs, you can open a Github issue tracker and assign corresponding authors to resolve the issue.

Releasing the package

  • The most easy way is to use devtools::release(). It will build the package and perform R CMD check one last time. Then it will ask your a few question and upload the package for you. After that, you should receive an email notifying you of the submission and asking you to approve it.

  • After the new version is on CRAN, rebase the \devel branch and ask all author to rebase their current working branch. Tag the release using git tag. Change the version number for both \master branch and \devel branch to prepare next release.

Clone this wiki locally