Checklist

Pre-Release

Start release planning immediately after each release according to the section Post-Release below - maybe there is actually not pre-release phase - to be verified

Freeze Phase

• Create the release on the QA server
• Inform developer of the freeze
• Create the release branches
• Define the version of the modules based on semantic versioning
• All relevant tickets are assigned to epics
• Check the Continuous Integration in details
• Inform the implementers about the User Acceptance Test (UAT) timeline (Beta version)
• Add user account on the QA server

Alpha Phase

• Create release instance using the released modules
• Perform some basic testing
• Claim: create/review/process
• Registration: create/update familly/insuree
• Enrollment: create policy and contribution
• Meta data: create/update location/product/user/role/pricelist/itemslist/servicelist
• Make sure defects are assigned to developers
• Do developer tests

Beta Phase

• Update the PyPi, NPM module when code change was done
• Check that the release instance use the latest modules
• Do User-Acceptance-Testing (UAT)
• Ensure deployability with Docker (Quickstart installation guide / Docker compose)

RC Phase

• Update the PyPi, NPM module when code change was done
• Check that the release instance use the latest modules
• Start collecting the documentation from developers

GA Phase

• Merge release branches with main
• All affected repositories (GitHub, Pypi.org, http://npmjs.com , etc.) are tagged and versioned according to Version management and contain complete release notes on GitHub
• All source components link to the correct repository on GitHub, have the correct version, valid release notes and are reasonably named to similiar repositories / package manager
• Publish the release branch on PyPi and NPM (required to check the packaging)
• Analyze linked issues as an anonymous user
• All links on the release page and release sources page are working and are helpful; Dates are correct and the status is “GA”
• All assigned tickets are marked “Done” or pushed to the next release
• “Highlights” of the release are written and coherent
• Ensure that the Release page points to the correct “Release Sources Page” e.g. Sources Release 2022-04 for Release 2022-04
• Update the openimis.json to use only official version (not rc) on assembly modules
• Update demo server
• Installation guide / Installation and Country Localisation supports installation of the latest release
• Formulate release notes in current release (Releases) and forward it to co-ordination desk for promotion (e.g. newsletter, Twitter)

Post-Release

Start preparing the next release immediately after the current release.

• Create the release page (e.g. Release 2022-04) for the following release and make sure it appears correctly on Releases
• Define milestones according to the framework in Releases
• Create the relevant epics for the new release (e.g. Release 2022-10) in Jira and add them to the release page
• Create a clean Release Checklist for the next release (e.g. Release 2022-10)
• Ensure the documentation is up2date
• User Documentation http://docs.openimis.org/en/latest/ / http://docs.openimis.org/fr/latest/
• Tutorials on YouTube are up-to-date / not misleading
• Developer Starter Kit reflects latest release

Following need to be integrated

Installation Guide / Configuration / Other

• “Technical Requirements” / Connectivity & theoretical infrastructure required reflects latest release

Sandbox Landscape Sandbox Landscape

• Demo: openIMIS Instance and Wiki page are up to date
• Release: openIMIS Instance and Wiki page are up to date
• Sandbox Landscape Other instances are up to date / compatible with Demo: openIMIS / Release: openIMIS