forked from r4ds/bookclub-rpkgs
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path22-releasing-to-cran.Rmd
138 lines (83 loc) · 4.86 KB
/
22-releasing-to-cran.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
# Releasing to CRAN
How to prepare and release a package to CRAN
## preparing for submission
To get your package ready to release, follow these steps:
1. Pick a version number. (advanced from the existing development version with `.9000` suffix)
2. Run and document `R CMD check`.
3. Check that you’re aligned with CRAN policies.
4. Update `README.md` and `NEWS.md`.
5. Submit the package to CRAN.
6. Prepare for the next version by updating version numbers.
7. Publicise the new version.
## submission process & test environments
- Don't do it manually - just use `devtools::release()`
- Include a `cran-comments.md` file (`usethis::use_cran_comments()`) to describe the results from an R CMD CHECK and the systems that it was run on (those on your system, rhub or GitHub actions)
CRAN runs on Windows, Mac OS X, Linux and Solaris. You don't need to test on all but you need to test on some and mention in the comments which you used.
devtools::release() suggests that you test using rhub - I'm not sure what the difference is between this and the checks done by GitHub actions (if there is any)
If you have an OS-specific problem:
(1) use a virtualisation tool so that you can debug locally
\>
(2) send repeatedly to GitHub with actions to test on problematic system
\>
(3) send to CRAN and hope for the best
## check results
- No `ERROR`s or `WARNING`s
- avoid as many `NOTE`s as possible - if they can't be avoided, be open about it in the `cran-comments.md`
- There will always be a `NOTE` for the first release of a package to CRAN, so it's worth mentioning this in the `cran-comments.md` if you're releasing your package for the first time as well.
## reverse dependencies
- it's your responsibility to ensure that downstream packages are not broken by your update
- use `{revdepcheck}` rather than the superseded `devtools::revdep_check()`
- `usethis::use_revdep()` calls revdepcheck functions and sets things up nicely to incorporate github actions and an email notification - not sure what the current state is though since revdepcheck isn't on CRAN
- if you do cause breaking changes, then mention in the `cran-comments.md` that you have notified downstream package maintainers about the upcoming changes.
## CRAN policies
- stable email address
- copyright in `DESCRIPTION` file
- make all reasonable efforts to get package working across platforms
- do not make external changes without explicit user permission:
- global environment
- writing to file system
- installing packages
- quiting R
- sending info over internet
- opening other programs
- don't submit updates too frequently: every 1-2 months at most
## other pre-submission checks
```r
goodpractice::gp()
```
## release using `devtools::release()`
- builds package and runs R CMD CHECK one last time
- prompts the user to do final checks including spelling, checking on rhub, committing all changes etc
- uploads the package bundle to CRAN and includes `cran-comments.md`
Afterwards, you'll get a confirmation email from CRAN (to the maintainers email). Once approved, the CRAN maintainer will run the checks and get back to you.
## post-release
If you get rejected:
- no need to respond to the email
- fix problems identified and include a `## Resubmission` section at the top of `cran-comments.md` showing that it is a resubmission and listing the changes that you made since the previous, rejected submission.
If you get accepted:
- success!
- when you did the submission, a `CRAN-SUBMISSION` or `CRAN-RELEASE` file was created. You don't need to commit this to GitHub. I usually just wait until it's accepted (hopefully) and when it is, run: `usethis::use_github_release()`. This creates a draft release on GitHub which you can then submit online.
- add the `.9000` suffix to the version on GitHub to indicate that it's the development version
## publicising it
- tweet about it with #rstats
- post about it on a blog
- send it to the [r-packages mailing list](https://stat.ethz.ch/mailman/listinfo/r-packages)
## Meeting Videos
### Cohort 1
`r knitr::include_url("https://www.youtube.com/embed/isKbovi62k4")`
### Cohort 2
`r knitr::include_url("https://www.youtube.com/embed/5VAvPvL18I0")`
### Cohort 3
`r knitr::include_url("https://www.youtube.com/embed/QOKMXNn1X5o")`
<details>
<summary> Meeting chat log </summary>
```
00:48:13 Brendan Lam: I don't know what CRAN reviews, but ROpenSci is pretty transparent about how they do software review: https://devguide.ropensci.org/
01:00:06 Arun Chavan: omg
01:03:13 Brendan Lam: Thanks Collin! You've done an exceptionally good job leading this cohort.
01:05:48 Arun Chavan: https://rfordatascience.slack.com/archives/C0183F9UC2V/p1659977487900379
01:06:22 collinberke: https://rfordatascience.slack.com/archives/C0183F9UC2V/p1659977487900379
01:08:19 collinberke: https://avehtari.github.io/ROS-Examples/
01:11:12 Brendan Lam: Same
```
</details>