-
Notifications
You must be signed in to change notification settings - Fork 4
ServerReleaseProcess
Merge the develop branch into the main branch. Releases come from the main branch. Our goal is to have the develop branch ready for release at any time, so unless a specific project is ongoing this should not be a big deal.
We use semantic versioning for this project. Releases that include major new functionality or have effects on backwards compatibility become feature releases (the minor version number is incremented). Almost anything else becomes a point release (the release number is incremented). However, you probably won't know whether this is a feature release until you're done preparing the release notes.
- Go to the Github releases page. This page shows release notes for previous releases. You'll be reproducing the release notes format for the new release.
- Click "Draft a new release" to go to the new release page.
- The target branch is
main; you made sure of that by mergingdevelopintomain. - Prepare the release notes. This is the hard part! Save your work as a draft as necessary.
- Set the version number based on what you discovered while preparing the release notes.
- The release title is the same as the version number.
Generally speaking, we group release notes into these categories and list them in priority order, so that the most important changes are at the front:
- Breaking functionality
- New features
- Improvements
- Bug fixes
- Other changes
Anything that has no visible effect on administrators or users (like refactoring) should go into "Other changes".
First, go through NYPL's Jira instance looking for server-side tickets that have been completed but don't have a release version. Here's a good search to run.. Not every ticket you see needs to be added to the release notes--some of the tickets are tasks that didn't result in changes to the code base.
For each ticket, write a brief explanation of the change in release note format and link to the ticket itself.
Make a note of when the prior release happened. This list is sorted by the date the ticket was updated, and you shouldn't have to go past that date -- anything prior to that date should have been considered for the prior release. At worst, you might discover that you need to update the release notes for a previous release.
Every code change is supposed to correspond to a ticket on nypl.jira.org, but sometimes changes slip through the cracks. That's why it's also necessary to go through the list of recently merged pull requests for circulation and core.
Each PR should mention one or more tickets on nypl.jira.org, either in a comment or in the name of the branch itself. If it doesn't, try and match the PR to one of the tickets you already wrote up. If it matches one, add a comment to the PR linking to the ticket. If it doesn't match, the change probably went in with no ticket. Write up the change in release note format and link directly to the PR.
By this time you should know whether a point revision or a feature release is appropriate, and thus what the new version number is. Go through all the jira.nypl.org tickets you linked to and set their "Fix Version" to the new version number. Our standard for naming circulation manager releases in Jira is "[release number]cm", e.g. "3.1.1cm". This is to distinguish between releases of the circulation manager, and releases of other projects like SimplyE.
Once you're ready, click "Publish release". This will trigger a build of a Docker image on Docker Hub, tagged with the release version number. This is the Docker image that most hosting organizations deploy to their servers.