Release Checklists

Release Checklist

• Create a new branch from main called release-X.Y.Z

• Update version number in DESCRIPTION and check that the Remotes: is up-to-date

• Update NEWS for the changes in this version

• commit, push changes, and create pull request

• get a review from another member of the Hubverse dev team and merge on approval

• add new tag (annotated (-a) or signed (-s) preferred) with the name “ X.Y.Z” and push

  # example: create a signed (-s) tag for version 3.3.3
  git tag -s 3.3.3 -m '<short explanation of what changed>'
  git push --tags

• create a release on github from the new tag

Post Release Checklist

Immediately after the release, follow these steps to set the version back to development

• Create new branch from main called post-release-X.Y.Z
• Add .9000 to the version number in DESCRIPTION (to indicate in development version)
• Add a new heading to NEWS.md: ## <package name> (development)
• commit, push changes, create a pull request
• merge (with or without approval)

Subsequent PR Checklist

Subsequent PRs are business-as-usual development. All PRs are tested against the development versions of packages and must work before being merged.

It is important to remember that PRs should focus on independent features. If you want add a new feature and fix a bug, these should be two separate PRs. This strategy reduces the size of the PR, making it easier to review.

• Create a new branch from main called <initials>/<feature>/<issue>. (e.g. ak/change-check-fail-class-and-print/111, which was authored by Anna Krystalli to change the check/fail class and print methods to fix issue #111).
• Update NEWS.md (be sure to acknowledge non-core contributors by tagging their GitHub handle and version number)
• Get review from a member of the hubverse team and merge into main on approval.

Caveats:

1. You should not change the development version number, unless there are important feature changes that are required by an upstream package (see more about the development version number).
2. Review often brings up potential non-blocking features/bug fixes that are orthogonal to the original PR. In these cases, instead of creating a PR to merge into the original PR, it’s best to create a new issue from the PR review and, after merging, create a new PR to fix that issue. This helps keep disparate bugfixes and features separate.

Hotfix Checklist

A hotfix is a bug fix that is independent from in-development features and needs to be deployed within a day. Details on hotfixes can be found in vignette("hotfixes", package = "hubDevs"). To patch and release a hotfix, follow this protocol:

• Create a new branch from the latest tag using <author>/<hotfix>/<issue>

  (main)$ git switch --detach 0.14.0 # checkout the tag
  ((0.14.0))$ git switch -c znk/hotfix/143 # create a new branch
  (znk/hotfix/143)$

• Write a test, fix the bug, commit, and push (do not bump the version number yet)

  (znk/hotfix/143)$ git commit -m 'hotfix for #143'
  (znk/hotfix/143)$ git push -u origin znk/hotfix/143 # push the hotfix

• Create a pull request, get a review from another hubverse developer, and confirm that checks pass (Do not merge yet)

• Update the NEWS and bump the patch version in the DESCRIPTION

• Release from the hotfix branch

  (znk/hotfix/143)$ git commit -m 'bump version to 0.14.1'
  (znk/hotfix/143)$ git tag -s 0.14.1 -m 'flipped retroencabulator switch option'
  (znk/hotfix/143)$ git push
  (znk/hotfix/143)$ git push --tags

  At this point, there will be a conflict on the NEWS and DESCRIPTION, but that’s because you confirmed that it worked in the previous step.

• Create the release from the tag on github or using GitHub’s CLI tool: gh release create 0.14.1

• Resolve conflicts in PR and merge into main.