Page Comparison

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. 

...

Recently there were several kind of releases been completted, therefore both of them will be described here. 

1. General Release of Feature Release *.

This kind of Release performed to rollout some scope of planned changes, as usual it carried out on regular basis, at the end of group of sprint's cycles etc.

...

_{This release includes minor bug fixes for edge-oai-pmh module (Q2/2020).
https://issuesfolio-org.folioatlassian.orgnet/browse/EDGOAIPMH-49}

5) git commit -m "Update NEWS" NEWS.md (commits changes in release notes files);

...

_{This release includes minor bug fixes for edge-oai-pmh module (Q2/2020).
https://issuesfolio-org.folioatlassian.orgnet/browse/EDGOAIPMH-49}

8.3) set flag "This is pre-release" and click "Safe draft".

...

12) Mark release ticket in Jira as "AWAITING BUGFIX DEPLOYMENT" (depends omn the current workflow process in jira) and close it.

13) Make release in Jira and add next versions^*. 

...

14) 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}

^* Sometimes there is need to prepare feature release tatally form mainline. That occurs when all the latest features from development needs to be included in release. Some modules, as mod-inventory-storage for example, fall under this category. One of latest trelease was prepared with this approach - 19.3.0. maily the flow differs no so much and we mention here the main steps:

1. Creates a long-live/release branch from mainline, if not exists before. For mentioned release 19.3.0 it was b19.3 branch.
2. Prepare temporary release branch, tmp-release-19.3.0 for example, and do all release steps mentioned above there.
3. After merging PR of temporary release branch (tmp-release-19.3.0 in our example) into the long-live/release - b19.3 branch we needs to update version in mainline.
4. Create a temporary branch like the tmp_post-release_19.3.0 from master branch and increase version in pom file to the next number, in our example it will be the 19.3.1-SNAPSHOT.
5. Merge PR of tmp_post-release_19.3.0  into the mainline.

2.

...

Bugfix/Hotfix Releases.

This kind of release require cration creation (if none)  or reusing reuse 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-live" branch b19.2 (needs to be create if not exists yet).

To create "long-live" branch please folow these steps: *

1) git checkout -b b19.2 v19.2.0 (creates release branch from last recent relase tag. So that this bugfix release will be based on previous general release point, i.e.  - release v19.2.0.);

...

4) git push (push changes to git stash server).

 ^*Some of the steps from 2 to 4 can be skipped in version in pom.xml is correct for preparing a release, if don't need to be increced (after prev. feature release, for example).

Now if we have or already prepared "long-live" branch, please follow these steps to prepare bugfix release:

1) git checkout b19.2 (switch into "long-live" release branch);

2) Create a reease release branch from there, for example: MODINVSTOR-524/release-19.2.3 (<release_ticket>/<release_branch_name>):

git checkout -b MODINVSTOR-524/release-19.2.3

3) Cherry pick into prevoiusly created release branch all needed commits from mainstream development branch, i.e. master. Make any extra fixes, if any changes needed, and commit them into previously created release branch^*.

git cherry-pick <commit_hash>

^*Don't forget to back porting extra fixes into mainstream development branch, i.e. master, if these changes valuable not only for particular bugfix release.

...

6) 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") *;

6.1) commit version number changes made in the pom.xml file:

git commit -a -m "Prepare for next development iteration"

* This step can be skipped if pom.xml currently contains correct number of preparing release.

7) 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);

8) git push origin MODINVSTOR-524/release-19.2.3 && git push --tags origin MODINVSTOR-524/release-19.2.3 (pushing local changes, release notes in this case, with tags to remote stash. These changes are pushed to remote "long-live" branch b19.2)

9) 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,

...

_{Change permissions location for oai-pmh view (MODINVSTOR-524)}

_{https://issuesfolio-org.folioatlassian.orgnet/browse/MODINVSTOR-524}

10.3) press "Publish release" green button.

...

12) Mark release ticket in Jira as "AWAITING BUGFIX DEPLOYMENT" (depends omn the current workflow process in jira) and close it.

13) Make release in Jira and add next versions^*. 

...

^{`mod-inventory-storage 19.2.3` has been released https://github.com/folio-org/mod-inventory-storage/releases/tag/v19.2.3}