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:

• Increment version number and remove .99 suffix. For example, 0.9.2.99 becomes 0.9.3.
• Pass R CMD check.
• Make a branch with ggplot2-<version>-rc, and push the branch.
• Email ggplot2, ggplot2-dev, and the maintainers of packages that depend on ggplot2.
• Plan next release by selecting issues to attack.

If problems arise during the RC period, we make fixes on the branch. Those fixes later 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 and ggplot2-dev mailing lists.

Development phase

• Increase the version number with a .99 suffix, to indicate that it is a development version. For example, after branching off the 0.9.2 release candidate, the development branch will have a version number of 0.9.2.99.