Skip to content

Release management process

Michael J. Giarlo edited this page Feb 9, 2017 · 32 revisions
  1. Does the release require QA, usability testing, or an accessibility audit? Schedule that to happen before cutting the final release if needed. Lean on the community to help with QA; on the UXIG to help with usability testing; and on Colin Fulton to help with targeted accessibility audits. Ping Mike Giarlo (serving as product owner for Sufia) for assistance with coordination.
  2. Bump the version number in version.rb to a SemVer-appropriate version; feel free to consult others (via Slack, hydra-tech, or a Hydra Tech call) if you're not sure.
  3. Modify the README and the install template to replace all instances of the past version with the new version.
  4. Add, commit, and push your README and version changes directly to the master branch of the upstream repository.
  5. Release the gem to rubygems.org:
  • If this is your first time pushing to rubygems.org for a Hydra project
    • Create an account at rubygems.org if you haven't already, or make note of your rubygems.org email address.
    • Ask on Slack or hydra-tech about making you an owner of the gem on rubygems.org. (Your rubygems.org email address and GitHub username need to be added to this script, and then someone who already has owner access needs to run that script.)
    • Ask on Slack or hydra-tech about adding you to the Owners team in the projecthydra GitHub organization.
    • If you have not yet, set up ~/.gem/credentials according to these instructions.
  • Run the rake release task.
  1. Create release notes in GitHub. In the new release, include at least a block with upgrade notes and a block showing the changelog -- see script changelog.sh for help generating changelog entries. (See an example.)
  2. Update the Hydra Stack Built-in Feature Checklist to indicate features that have been added, removed, or moved to a different layer of the stack.
  3. Send a release message to hydra-tech, hydra-community, and hydra-releases describing the changes (which you can copy from the GitHub release). (This assumes you've already joined those three lists. Do that first!) It may be helpful to base your message on a prior example, which also contains some new text explicitly thanking contributors, which you can get from the changelog.