-
Notifications
You must be signed in to change notification settings - Fork 24
Preparing a new CRAN Release
This page collects guidelines for preparation of package release.
-
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 ofrefund
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.
-
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 withdevtools::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
andWARNINGs
. A package that contains any errors or warnings will not be accepted by CRAN. I also findNOTEs
are also unacceptable in most cases so try to eliminate as manyNOTEs
as possible. After the checks are done and passed, documentcran-comments.md
properly in master branch. -
If you see any
ERRORs
,WARNINGs
andNOTEs
, you can open a Github issue tracker and assign corresponding authors to resolve the issue.
-
The most easy way is to use
devtools::release()
. It will build the package and performR 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 usinggit tag
. Change the version number for both\master
branch and\devel
branch to prepare next release.