Release Procedure [Back-End]

High level description of the steps required to perform a release.  

Community Release Guides

1. Before you do anything, communicate with the team. Let team know during daily standup that you're planning on starting a release.
2. Determine the release and next versions - See https://dev.folio.org/guidelines/contributing/#version-numbers - Discuss with the team if unsure about either.
3. Create a release branch (See Best Practices)
4. Update the NEWS/CHANGELOG.md file (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. Double-check that all needed was included in the NEWS/Changelog by comparing with GitHub Full Changelog (for example, https://github.com/folio-org/mod-remote-storage/compare/v1.4.2...v1.5.0).
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: run the maven command to create the tag and prepare for the next release, then push the pom file changes AND tags
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 release is created on long-live branch (typically during hotfix/bugfix releases) create PR to master to sync NEWS.md both in long-live and master branch.
11. If release is created from master branch create corresponding long-live branch.
12. 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.
13. Announce your release in the #acquisitions-dev and #releases channels with a link to the release
14. 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.
15. Create a PR updating platform-complete files as per https://dev.folio.org/guidelines/release-procedures/#platform-edit-steps.  Don't forget install-extras.json for edge APIs!
16. Move your JIRA to "In Review" and assign to the Scrum Master.
17. The Scrum Master can safely close the story and update the JIRA releases/versions

Best Practices: