-
Notifications
You must be signed in to change notification settings - Fork 124
Release management process
Daniel Pierce edited this page Mar 28, 2024
·
54 revisions
Need to release a version of Hyrax? Here is a checklist!
Note: These instructions use version 1.1.0 for illustrative purposes. Replace that with an appropriate version number.
- Does the release require QA, usability testing, or an accessibility audit? Schedule that to happen before cutting the final release if needed. Work with the Hyrax Product Owner to set up quality assurance testing and accessibility audits.
- If the release contains locale text changes, update all available translations to ensure internationalization is consistent across languages.
- Bump the version number in version.rb to a SemVer-appropriate version; feel free to consult others (via Slack, samvera-tech, or a Samvera Tech call) if you're not sure what version to choose.
- Modify these files to replace all instances of the past version with the new version:
- Change the tag for the installation template in the README from, e.g. (if bumping from 1.0.0 to 1.1.0),
rails new my_app -m https://raw.githubusercontent.com/samvera/hyrax/v1.0.0/template.rb
torails new my_app -m https://raw.githubusercontent.com/samvera/hyrax/v1.1.0/template.rb
. - Add, commit, and push the above changes directly to a branch (e.g.
prep-v1.1.0
) of the upstream repository and create a "Prep v1.1.0" PR. - While waiting for PR approval, create a release in GitHub.
- The release name and tag should be in the format
hyrax-vx.x.x
(e.g.hyrax-v1.1.0
). (Note: Thehyrax-
prefix is needed to avoid conflicts with old sufia era tags.) - The auto-generation tool will provide a list of the pull requests since the previous release organized according to any
notes-*
tags on the PRs. These can be edited as needed, or tags added to PRs in the "Other" section. Typically we remove the user specific @ mentions and the list of first time contributors to match the format of prior release notes.
- The release name and tag should be in the format
- Once the Prep PR is approved and merged, publish the release on GitHub.
- Release the gem to rubygems.org via
rake release
. (See below if this doesn't work.) - Update the Hyrax Feature Matrix to indicate features that have been added, removed, or moved to a different layer of the stack.
- Send a release message to samvera-tech, samvera-community, and samvera-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.
- Send the release message to the #general channel on the Samvera Slack. Celebrate! 🎉
If this is your first time pushing to rubygems.org for a Samvera gem:
- Create an account at rubygems.org if you haven't already, or make note of your rubygems.org email address.
- Make sure your rubygems.org account has multi-factor authentication enabled.
- Ask on Slack or samvera-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 samvera-tech about adding you to the Admins team in the samvera GitHub organization.
- If you have not yet, set up
~/.gem/credentials
according to these instructions.
Then try again.
Ask the Hyrax Tech Lead if you need help with, or have questions about, any of the steps in the release management process.