Skip to content

CRAN maintainer communication standards and release checklist #5714

@tdhock

Description

@tdhock

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)

  • how frequent should regular CRAN releases be? Suggestion: twice per year.
  • 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).
  • 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.
  • What steps/checklist should be done before CRAN release? Suggestion: at least make sure R CMD check is ok on data.table, and revdep checks are ok (no revdep check necessary for patch release). Matt has a more extensive checklist https://github.com/Rdatatable/data.table/blob/master/.dev/CRAN_Release.cmd Also would be good to run performance testing 1 month prior to a regular release, so then there can be some time to fix any performance regressions. (Not really possible currently, but I am currently working on performance testing infrastructure with a couple of people)

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions