Page Comparison

...

1. Mark the release issue as in-progress in JIRA, make sure it has the expected fix version
2. Create a temporary branch for the release from the head of the mainline (usually named master). The name should include the JIRA issue identifier and the version to be released, e.g MODUSERS-245-release-17-3-0
3. Check that the current version (as a pre-release) matches the intended release version e.g. 17.3.0-SNAPSHOT matches 17.3.0 
4. Update the news.md  file with changes included in the intended version that are relevant to the users or operators of the system e.g. changes to interfaces provided or required. Where relevant, each line should include a reference to a JIRA issue.  Also make sure to remove the "IN-PROGRESS" and put in the date of release.
5. (Optional) replace the issue identifiers in the news with links. Adam Dickmeiss provided a script to do this:

   1. sed 

      sed

      -E -i "s@

      \

      ([ (]

      \

      )

      \

      ([A-Z]

      [A-Z][A-Z]*-[

      {2,}-[0-9]

      [0-9]*\)\

      {1,})([ )]

      \

      )@\1[\2](https://issues.folio.org/browse/\2)\3@g" 

      <

      NEWS.md

6. Run mvn release:prepare  locally, remember to change the next release version to the next minor version e.g. 17.4.0  instead of patch version as suggested
   1. It's possible for problems with the pomfile to surface at this stage, such as the use of snapshot dependencies.  You may wish to do a dryrun of the prepare first (there are instructions for doing this in the maven docs).  If problems do surface, back up and issue the fixes as a separate PR, then restart the release process when they are merged into main.
7. Compare the branch to the head of mainline, making sure that the news and next version are as expected
8. Raise a pull request for the temporary branch e.g. for mod-users 17.3.0
9. Only when the branch and pull request builds have succeeded, push the tag generated by the release preparation
10. Build the release tag in Jenkins e.g. for mod-users 17.3.0
11. Create a github release including the changes from the news file e.g. for mod-users 17.3.0
12. Merge the pull request (and delete the temporary branch)
13. Check the mainline build of the module after merge (if this fails, it can cause environment build failures due to trying to use the release version rather than next snapshot)
14. Mark the version as released in JIRA. Should include link to github release. Will need to override open issues as the release issue will still be open
15. Create new patch (e.g. 17.3.1 ) and minor (e.g. 17.4.0 ) or major (e.g. 18.0.0 ) versions for potential future releases (as not all developers have permissions to create versions)
16. Announce the release in #releases Slack channel, including a link to the github release e.g. for mod-users 17.3.0
17. Close the release issue in JIRA

...

This can be done with a search on the intended release version e.g. the issues intended to be included in mod-users 17.3.0  can be found with this query

Analyse discrepancies between these lists

...