Repository navigation
CRAN maintainer communication standards and release checklist #5714
Description
Activity
- changed the title
[-]CRAN maintainer release checklist[/-][+]CRAN maintainer communication standards and release checklist[/+]on Oct 31, 2023 how frequent should regular CRAN releases be? Suggestion: twice per year.
I presume the qualification 'regular' means 'outside of bugfixes / CRAN-required changes' in which case twice a year seems reasonable. I would say that once a 'significant' feature is merged it should be released to CRAN, for some value of 'significant', rather than a schedule.
Does the CRAN maintainer need to ask other people on github to approve the CRAN submission? Suggestion: create an issue to announce the submission, and make sure there is general consensus that it is ok to go ahead (nobody has expressed big blocking concerns).
I think that an announcement of a release is a good idea, though I'd recommend the master branch be kept in a releaseable state. I think the role immediately below 'CRAN maintainer' should be authorized to mark an issue with special 'blocking' status if they believe the master branch is not in a releaseable condition. And if any open issues have that status, the package should not be released without the CRAN maintainer providing an explanation. The specifics of what qualifies as a blocking issue is probably a matter of judgement, but serious bugs with new features, as well as segfaults would probably be blocking. I don't think the CRAN maintainer should need positive approval for a release, especially for things like CRAN-required changes (which are usually trivial and urgent).
What steps should the CRAN maintainer take in response to email requests for updates from CRAN? Suggestion: post an issue on github, ask others to help fix.
Agreed. Though the CRAN maintainer should be ultimately responsible for the resolution of the issue. That is, in the absence of anyone agreeing to a fix, or providing a fix within the deadline, it should fall to the maintainer to fix (or negotiate with CRAN as an absolute last resort). I anticipate most requests from CRAN would be pretty trivial.
Reacted by Toby Dylan Hocking, Tyson Barrett and minemRhow frequent should regular CRAN releases be? Suggestion: twice per year.
Seems like a reasonable target. It may take a few iterations to get the process streamlined enough to where this makes sense in practice.
Does the CRAN maintainer need to ask other people on github to approve the CRAN submission?
Yes, I think having a release tracker issue & associated milestone is the best practice. In general it is very common to "bump" some issues from current to next milestone, without much oversight. Any contention about which issues "need" to be fixed for a release should be discussed in the release tracker issue.
What steps should the CRAN maintainer take in response to email requests for updates from CRAN? Suggestion: post an issue on github, ask others to help fix.
Agree, except possibly in the case of security concerns (I'm not aware of any precedent for that coming up).
What steps/checklist should be done before CRAN release?
Yes, Matt's checklist is the best bet for a tried-and-true approach. Historically, each release produces some small tweak to the release script -- it has been fine-tuned by many release cycles. I'll add a reiteration of the above about milestone culling and release issue tracking as chores during the release cycle that transpire entirely on GitHub.
Reacted by Toby Dylan Hocking, Tyson Barrett and iagogv3
related to #5676 I would like to discuss what standards of communication should be expected between the person who submits data.table releases to CRAN (who I will call CRAN maintainer) and everyone else working on data.table, and also what the CRAN maintainer is expected to do (and how frequently)