ggplot2 release process

Notes on the ggplot2 release process

Categorizing issues

New milestones:

• bug-fix
• new-feature
• major
• blue-sky

Issues with no milestone = inbox

When an issue arrives, categorise into:

• one of the milestones above
• the current release milestone (if small/simple)
• not a real issue, and close.
• needs minimal reproducible example

Generally, try and stick with a "tick-tock" strategy, where we alternative between releases that focus on bigger features and releases that focus on bug fixing.

Releasing a new version

Release candidate phase

After issues resolved for a given release:

• pass R CMD check
• make a branch with ggplot2-<version>-rc, and push the branch
• email ggplot2-dev, and downstream maintainers
• plan next release by selecting issues to attack

If problems arise during the RC period, we make fixes on the branch. Those fixes then get merged back into master.

Release

When the package is accepted on CRAN:

• tag the last commit on the rc branch with ggplot2-<version> and push the tag:

  git tag -a ggplot-<version>
  git push origin --tags

• delete the -rc branch, with:

 git branch -d ggplot2-<version>-rc
 git push origin :ggplot-<version>-rc

• Email the ggplot2 mailing list