The purpose of this page is describing module release practical procedures. Mainly these steps are based on general "Release Procedure" but contains some of refinements found in the process of recent release procedures.
...
13) Annonce in Slack about a new release in the #release thread (example of message):
`edge-oai-pmh 2.2.1` has been released https://github.com/folio-org/edge-oai-pmh/releases/tag/v2.2.1
...
This kind of release require cration (if none) or reusing as named "long-live" branch, which contains only chnages prepared for this partucular release. Those branches has the name kind b19.2. In this description we goind to prepare build number 19.2.3 into the "long-lived live" branch b19.2 (needs to be create if not exists yet).
...
1) git checkout b19.2 (switch into "long-live" release branch);
TODO: create rerlease branch
TODO: pickup needed commits from mail development stream (master) into relaese branch
22) Create a reease branch from there, for example: MODINVSTOR-524/release-19.2.3.
3) Cherry pick into prevoiusly created release branch all needed commits from mainstream developemnt branch, i.e. master. Made any extra fixes if needed changes and commit them into release branch*.
git cherry-pick <commit_hash>
* Don't forget to back porting extra fixes into mainstream developmet branch, i.e. master, if these changes valuable not only for particular bugfix release.
4) vi NEWS.md (edits release notes file and add description of release's features. Example below)
35) git commit -m "Update NEWS" NEWS.md (edits release notes file and add description of release's features. Example below):
...
4) mvn versions:set -DnewVersion=19.2.3-SNAPSHOT (here we set the version of bugfix release, it conists of preparing relese's number with added prefix: "-SNAPSHOT");TODO: add commit of version changes in pom.xml
4.1) commit version number changes made in the pom.xml file:
git commit -a -m "Prepare for next development iteration"
5) mvn --batch-mode -DautoVersionSubmodules=true release:clean release:prepare (runs maven release buld process. Here release number and rest of data set up automatically without any dialogs, based on version's set from previous step);
6) git push && git push --tags (pushing local changes, release notes in this case, with tags to remote stash. These changes are pushed to remote "long-live" branch b19.2)
TODO: create pull request of pushed remote release branch to long-live branch b19.2.
TODO: After merging, rest of release related finishing steps nededs to be completted, see below.
7) Run release job (log in to Jenkins and trigger Build Now). Please don't forget to build release's envitronment !!!7) Go to the module's repository on GitHub and create a new "Pull request" of pushed relaese branch (MODINVSTOR-524/release-19.2.3) into the "long-live release branch - b19.2 in or case,
Wait until Pull request will be merged into "long-live" branch.
8) Create a new release's description in appropriate module repository on GitHub. For example, for mentioned EDGEMOD-OAIINVENTORY-PMH module STORAGE module there is Release v19.2.3 created. To do so:
...
8.3) press "Publish release" green button.
9) Run release job:
9.1) log in to Jenkins, choose appropriate tag on the "Tags" tab (was created by push operation of the step 6th)
9.2) trigger Build Now.
Please don't forget to build release's envitronment !!!
10) Mark release ticket in Jira as Released "AWAITING BUGFIX DEPLOYMENT" (depends omn the current workflow process in jira) and close it.
and add next versions.
11) Made release in Jira if you have required permission for that, add next versions.
1012) Annonce in Slack about a new release in the #release thread (example of message):
`mod-inventory-storage 19.2.3` has been released https://github.com/folio-org/mod-inventory-storage/releases/tag/v19.2.3