-
Notifications
You must be signed in to change notification settings - Fork 755
Release
-
from within R, run
roxygenise()
, ordevtools::document()
to update documentation -
from the command line, run
R CMD check
Passing R CMD check
is the most frustrating part of package development, and it usually takes some time the first time. Hopefully by following the tips elsewhere in this document you'll be in a good place to start - in particular, using roxygen and only exporting the minimal number of function is likely to save a lot of work.
One place that it is frustrating to have problems with is the examples. If you discover a mistake, you need to fix it in the roxygen comments, rerun roxygen and then rerun R CMD check
. The examples are one of the last things checked, so this process can be very time consuming, particularly if you have more than one bug. The devtools
package contains a function, run_examples
designed to make this somewhat less painful: all it does is run functions. It also has an optional parameter which tells it which function to start at - that way once you've discovered an error, you can rerun from just that file, not all the files that lead up to.
Once you have passed the checking process, you need to upload your package to CRAN. The checks will be run again with the latest development version of R, and on all platforms that R supports - this means that you should be prepare for more bugs to crop up. Don't get excited too soon!
-
update
NEWS
, checking that dates are correct. Usedevtools::show_news
to check that it's in the correct format. -
R CMD build
then upload to CRAN:ftp -u ftp://cran.R-project.org/incoming/ package_name.tar.gz
-
send an email to
[email protected]
- this is optional, but if you don't you'll only hear back if something went wrong with the checking process.
Once all the checks have passed you'll get a friendly email from the CRAN maintainer and you'll be ready to start publicising your package.
Once you've received confirmation that all checks have passed on all platforms, you have a couple of technical operations to do:
-
git tag
, so you can mark exactly what version of the code this release corresponds to -
bump version in
DESCRIPTION
andNEWS
files
Then you need to publicise your package. This is vitally important - for you hard work to be useful to someone, they need to know that it exists!
-
send release announcement to
[email protected]
. A release announcement should consist of a general introduction to your package (i.e. why should people care that you released a new version), and as well as what's new. I usually make these announcements by pasting together the packageREADME
and the appropriate section from theNEWS
. -
announce on twitter, blog etc.
-
Finally, don't forget to update your package webpage. If you don't have a package webpage - create one! There you can announce new versions, point to help resources, videos and talks about the package. If you're using github, I'd recommend using github pages to create the website.