0 Project and board

...

Once development team is decide to release new interface version than previous one have to be closed.

All teams are responsible to update Interface Versions Provided by their modules prior release deadline as per release timeline.

New item for actual Interface Version Provided should be created in Interfaces epic, while the item representing an outdated Interface Version Provided should be Closed.

For example:

mod-kb-ebscojava module provides latest interface version - eholdings 2.0

During releasing new version of mod-kb-ebscojava new interface eholdings 2.1 has been provided.

Previous ticket for eholdings 2.0 should be closed.

New ticket in Interfaces epic eholdings 2.1 should be created.

2 Tracking RMB versions

All interfaces are ordered under following epic - 

...

raml-module-builder provides latest interface version - "RMB v 29.4.0"

During releasing new version of raml-module-builder new version "RMB v 30.0.0" has been provided.

Previous ticket for RMB v 29.4.0 should be closed.

New ticket in RMB epic "RMB v 30.0.0" should be created

3 Release epics

For each release appropriate release epics should be created.

All teams are responsible to create Stripes/RMB upgrade stories in the corresponding Jira projects and links them to corresponding epics provided by Release Coordinator for a particular release.

Following release checkpoints should be covered with separate epics:

1. Release preparation - upgrading to platform components if new version is provided
   1. Stripes (example: to manage process of upgrading to Stripes v4 epic - https://issues.folio.org/browse/FOLREL-341 has been created. Please create a tickets familiar to https://issues.folio.org/browse/UIEH-891 to track your effort and set epic to FOLREL-341 if upgrade is not required -> jira ticket could not be created)
   2. RMB (example: to manage process of upgrading to RMB v30 epic - https://issues.folio.org/browse/FOLREL-342 has been created. Please create a tickets familiar to https://issues.folio.org/browse/UIEH-891 to track your effort and set epic to FOLREL-342 if upgrade is not required -> jira ticket could not be created)
   3. OKAPI
2. Modules release
   1. Main release
   2. Bugfix release
   3. Hotfix release

As example see bunch of epics that are created for Q2 2020 

4 Tracking modules releases

Development team and PO should decide what responsible modules are going to be released.

When decision is agreed then separate ticket for module release should be created in specified Jira project.

Alignment of module and Jira project could be found at Team vs module responsibility matrix

4.1 Fix version

Fix version of Jira ticket should be named according to github module release number

4.2 Release epic providing

Release epic should be noted according to appropriate module release phase.

...

Following story 

4.3 Final interface version provided

Interfaces that are provided by module should be specified at 

Image Modified

4.4 Final interface version required

Interfaces that are required to module could be found at 

Image Modified

4.5 Used RMB version

RMB version that are required to module could be found at 

Image Modified

4.6 Notes, GitHub link and Docker Hub link

All information relates to additional notes, github link and docker hub link should be specified at Description field

...