Versions Compared

Key

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

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. 

...

Let assume that we need to prepare a new release with the number: 2.2.1 and the tag: v2.2.1. In term of mentioned above general instruction, perepared release number is: X.Y.1 (mentioned instruction was wrote written in context of version: X.Y.0).

...

7) git push && git push --tags (pushing local changes, release notes in this case, with tags to remote stash)

8) Run release job (log in to Jenkins and trigger Build Now). Please don't forget to build release's envitronment !!!9) Create a new release's description in appropriate module repository on GitHub. For example, for mentioned EDGE-OAI-PMH module there is Release v2.2.1 created. To do so:

98.1) go to module's Code page and pickup Releases tab;

98.2) click on the "Draft a new release" button and fill fields with data:

...

This release includes minor bug fixes for edge-oai-pmh module (Q2/2020).
https://issues.folio.org/browse/EDGOAIPMH-49

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

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

9.2) trigger Build Now.

Please don't forget to build release's envitronment !!!

10) Merge release's branch to the into the master. This will allow to  back porting created release's tag number (v2.2.1) into the mainstream development branch, i.e. master.

11) After successfull completion of all the build jobs on Jenkins environment, already prepared release on guthub GutHub (at the step 8th) can be publishpublished:

11.1) go to the module's Code page and pickup Releases tab;

11.2) choose prepared, at the step 9th 8th above, "draft release" v2.2.1, open it and press "Publish release" green button.

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

13) Make release in Jira and add next versions*

*Migh have extra permissions to perform this step.

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

...

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

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.

...

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,

...

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

and add next versions.

11) Make release in Jira if you have required permission for that, add next versions and add next versions*

*Migh have extra permissions to perform this step.

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