Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Before you do anything, communicate with the team.  Let them know during daily standup that you're planning on starting a release.
  2. Determine the release and next versions - See - Discuss with the team if unsure about either.
  3. Create a release branch (See Best Practices)
  4. Update the NEWS/ file (See Best Practices)
    1. Make use of JIRA and add any stories that have been completed in this version but are missing from the NEWS/Changelog file.
  5. Bump interface versions that have changed (minor number if backwards compatible, major number if breaking changes)
    1. N.B. Make sure all required interface versions have been released.  If not, raise the issue with the PO/Tech Lead.
  6. Commit and push your changes
  7. Create A PR (See Best Practices) and request approval.  If there are mistakes this is the time to identify them, BEFORE creating a tag.
  8. Once you have at least 2 approvals:
    1. Backend Only: Run the maven command to create the tag and prepare for the next release, then push the pom file changes AND tags
    2. UI Only: Create a tag.
  9. If the PR checks pass, DO NOT merge your PR yet...  Goto Jenkins, find your module, find your tag, and build it.  
  10. 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.
  11. Announce your release in the #acquisitions-dev channel and #releases channels with a link to the release
  12. Coordinate with the rest of the team before merging any PRs into master.  
    1. 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.
    2. 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.
  13. Move your JIRA to "In Review" and assign to the Scrum Master.
  14. The Scrum Master can safely close the story and update the JIRA releases/versions
  15. If the module has API tests:
    1. Create a branch of folio-api-tests
    2. Update all schema references so that the commit hash from the release's submodule is used instead of HEAD/master.
    3. Update all mock data references so that the commit hash from the release's submodule is used instead of HEAD/master.
    4. Create and push a tag of your branch.  Please follow the naming convention: <module name>-<release version>, e.g. mod-orders-3.0.0