Standard issue "template" for releasing a package
hadley opened this issue · 14 comments
For now, this issue is just a place to dump ideas as they occur to me. No need to implement yet.
Prepare for release:
* [ ] `devtools::check_win_devel()`
* [ ] `rhub::check_for_cran()`
* [ ] `revdepcheck::revdep_check(num_workers = 4)`
* [ ] [Polish NEWS](http://style.tidyverse.org/news.html#before-release)
* [ ] If new failures, update `email.yml` then `revdepcheck::revdep_email_maintainers()`
Perform release:
* [ ] Create RC branch (for bigger releases)
* [ ] Bump version (in DESCRIPTION and NEWS)
* [ ] `devtools::check_win_devel()` (again!)
* [ ] `devtools::submit_cran()`
* [ ] `pkgdown::build_site()`
* [ ] Approve email
Wait for CRAN...
* [ ] Tag release
* [ ] Merge RC back to master branch
* [ ] Bump dev version
* [ ] Write blog post
* [ ] Tweet
* [ ] Add link to blog post in pkgdown news menu
Template from <https://github.com/r-lib/usethis/issues/338>
Maybe with variation for first release?
* [ ] Check that description is informative
* [ ] Check licensing of included files
Would it work to add "Write blog post" after "Polish news", and replace current "Write blog post" with "Refine blog post"? Some bugs (and clumsy APIs) are revealed only when writing the blog post.
Do we need to add "Run devtools::document()" just in case? The pkgdown::build_site() call does take care of it, but that's too late.
Also perhaps: "Verify test coverage". Reduced coverage can be a hint for a subtle bug.
I'd suggest adding an item about making a PR to https://github.com/rweekly/rweekly.org with a link to the release notes (we have a section for new releases and one for new packages). 😺
I don't know if it'd be worth adding a dependency to gh, but here's a helper function for filing this directly form R:
gh::gh("POST /repos/:owner/:repo/issues", owner = "REPO OWNER HERE", repo = "REPO NAME HERE", title = "Prepare for release",
body = "Prepare for release:
* [ ] `devtools::check_win_devel()`
* [ ] `rhub::check_for_cran()`
* [ ] `revdepcheck::revdep_check(num_workers = 4)`
* [ ] [Edit NEWS / Release notes](http://style.tidyverse.org/news.html#before-release)
* [ ] If new failures, update `email.yml` then `revdepcheck::revdep_email_maintainers()`
Perform release:
* [ ] Create RC branch (for bigger releases)
* [ ] Bump version (in DESCRIPTION and NEWS)
* [ ] `devtools::check_win_devel()` (again!)
* [ ] `devtools::submit_cran()`
* [ ] Approve email
Wait for CRAN...
* [ ] `pkgdown::build_site()`
* [ ] Tag release
* [ ] Merge RC back to master branch
* [ ] Bump dev version
* [ ] Write blog post
* [ ] Tweet
* [ ] Add link to blog post in pkgdown news menu
Template from <https://github.com/r-lib/usethis/issues/338>")Tested here: batpigandme/palaver#2
The second (or a third) pkgdown::build_site() should happen after CRAN acceptance, so that the associated heading in NEWS picks up the release date vs. "unreleased".
@hadley If the package has compiled code, then I suggest these as well:
* [ ] `rhub::check(platform = "solaris-x86-patched")`
* [ ] `rhub::check(platform = "ubuntu-rchk")`
@gaborcsardi could we make rhub::check_for_cran() do that automatically?
We could, but you don't really need Solaris to get on CRAN, and it fails often, because of missing system libs. rchk has many false positives in my experience.
@gaborcsardi @hadley Also for packages with native code: rhub::check_with_sanitizers()
Maybe we should add a check_compiled() to rhub?
Well, we can just add them to check_for_cran(). I can relatively easily update it to send a single email after all checks are done.
Maybe add "Check for recent CRAN policy changes"?