- Before you do anything, communicate with the team. Let them know during daily standup that you're planning on starting a release.
- Determine the release and next versions - See https://dev.folio.org/guidelines/contributing/#version-numbers - Discuss with the team if unsure about either.
- Create a release branch (See Best Practices)
- Update the
NEWS/CHANGELOG.mdfile (See Best Practices)
- Make use of JIRA and add any stories that have been completed in this version but are missing from the NEWS/Changelog file.
- Bump interface versions that have changed (minor number if backwards compatible, major number if breaking changes)
- N.B. Make sure all required interface versions have been released. If not, raise the issue with the PO/Tech Lead.
- Commit and push your changes
- Create A PR (See Best Practices) and request approval. If there are mistakes this is the time to identify them, BEFORE creating a tag.
- Once you have at least 2 approvals:
- Backend Only: Run the maven command to create the tag and prepare for the next release, then push the pom file changes AND tags
- UI Only: Create a tag.
- If the PR checks pass, DO NOT merge your PR yet... Goto Jenkins, find your module, find your tag, and build it.
- If the tag build succeeded, Goto your github repo, merge the release's PR, click on releases, and draft a new release. Copy/Paste in the section of your NEWS into the release notes and save/publish.
- Announce your release in the #acquisitions-dev channel and #releases channels with a link to the release
- Coordinate with the rest of the team before merging any PRs into master.
- If there were interface/dependency changes there's a good chance multiple PRs will need to be merged together to prevent breaking the testing environment.
- The team may decide to hold off on merging any PRs until after the sprint demo. You don't want to be the reason why someone's demo isn't working.
- Move your JIRA to "In Review" and assign to the Scrum Master.
- The Scrum Master can safely close the story and update the JIRA releases/versions
- If the module has API tests:
- Create a branch of folio-api-tests
- Update all schema references so that the commit hash from the release's submodule is used instead of HEAD/master.
- Update all mock data references so that the commit hash from the release's submodule is used instead of HEAD/master.
- Create and push a tag of your branch. Please follow the naming convention:
<module name>-<release version>, e.g.