Versions Compared

Key

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

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
  •  Publish the release branch on PyPi and NPM (required to check the packaging) Inform the integrator implementers about the User Acceptance Test (UAT) timeline (Beta version)
    •  Add user account on the QA server

Alpha Phase

  •  create Create release instance using the released modules
  •  perform 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 developpersdevelopers

Beta Phase

  •  Update the PyPi, NPM module when code change was done
  •  Check that the release instance use the latest modules
  •  

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
  •  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 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
  •  Merge release branches with main Update demo server
  •  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)

Following need to be integrated

...

Releases Page Releases

  •  Analyze linked issues as a normal user (private projects hidden)
  •  All links are working and are helpful
  •  Dates and status of all releases are correct

...

...

Release

...

Sources

...

Page

e.g. Sources Release 2022-04

  •  All components are consistently versioned according to Version management
  •  All links are working and helpful
  •  All components link to the correct repository and version
  •  All components have correct “Release Notes”
  •  All components link to reasonably similiar named repositories / package manager

Release Notes

  •  Every effected component in the release specific sources page (e.g. Sources Release 2022-04) has an updated and complete change log in it’s repository

User Documentation

Installation Guide / Configuration / Other

Sandbox Landscape Sandbox Landscape

Anchor
findings
findings
Findings Release 2022-04

...