Release 5.1.0

[mrjones-plip]

Planning - CHT Community

• Create a GH Milestone for the release and add this issue to it. We use semver so if there are breaking changes increment the major, otherwise if there are new features increment the minor, otherwise increment the service pack. Breaking changes for the CHT relate to updated software requirements (for example: CouchDB, node, minimum browser versions), broken backwards compatibility in an API, or a major visual update that requires user retraining.
• Add all the issues to be worked on to the Milestone. Ideally each minor release will have one or two features, a handful of improvements, and plenty of bug fixes.
• Ensure that all issues are labelled correctly, particularly "UI/UX" and "Breaking change" labelled issues, if any.
• Ensure that "Regressions" are labelled with "Affects: " labels. The "Affects" label is used in a link in the Known Issues section of the release notes of that version so it has to match exactly. To make sure the label is correct go to the release notes and ensure the issue is listed.
• Identify any features and improvements in the release that need end-user documentation (beyond technical documentation improvements) and create corresponding issues in the cht-docs repo.
• Assign a maintainer as Release Manager for this release.

Development - Release Manager

When development is ready to begin one of the maintainers should be nominated as a Release Manager. They will be responsible for making sure the following tasks are completed though not necessarily completing them.

• Checkout to a new <issue>-update-version branch (eg: 1234-update-version) and set the version number in the package.json and package-lock.json. The easiest way to do this is to use npm --no-git-tag-version version <major|minor>. Once the version is updated, submit a PR to master branch.
• Ensure that issues associated with commits merged to master since the last release are closed and mapped to the milestone.

Releasing - Release Manager

Once the PR has been merged into master, and the master branch has the new version number, then the release process can start:

• Create a new release branch from master named <major>.<minor>.x in cht-core. Notify the community by creating a post titled <major>.<minor>.<patch> Beta Releases in the development category of the CHT forum using this template.
• Build a beta named <major>.<minor>.<patch>-beta.1 by creating a lightweight git tag (e.g. git tag <major>.<minor>.<patch>-beta.1) and then push the created tag.
• Once the CI completes successfully notify the community by adding a comment in the forum post created above using this template:

I’ve just created the `<major>.<minor>.<patch>-beta.1` tag. 
Please let me know if there’s any final update we need to make. 
If all is good, then in 24h, I will start the release. Thanks!

• The beta tag will automatically trigger the scalability build. Once it passes, check for the scalability results here. More info in the scalability documentation.
• Go to the Issues tab and filter the issues with is:issue label:"Affects: 4.x.x" , replace 4.x.x with the previous version number. Add any open "known issues" from the prior release that were not fixed in this release. Done by adding the correct Affects: 4.x.x label.
• Add release notes to the Core Framework Releases page:
  • Create a new document for the release in the releases folder.
  • Ensure all issues are in the GH Milestone, they have human readable descriptions, and that they're correctly labelled. In particular: they have one "Type" label, "UI/UX" if they change the UI, and "Breaking change" if appropriate.
  • Use this script to export the issues into our release note format.
  • Collect known migration steps, descriptions, screenshots, videos, data, and anything else to help communicate particularly important changes. This information should already be on the issue, but if not, prompt the change author to provide it.
  • Document any required or recommended upgrades to our other products (eg: cht-conf, cht-gateway, cht-android).
  • Add the release to the Supported versions and update the EOL date of the previous release. Update the status of any releases that are past their End Of Life date. Also add a link in the Release Notes section to the new release page.
  • Ensure that the release notes PR is merged before moving to next step.
• Create a new release in GitHub, with the naming convention <major>.<minor>.<patch>, from the release branch created above as the target branch. Click on the "Choose a tag" dropdown and create a tag for the release with the naming convention <major>.<minor>.<patch>. Add a link to the release notes in the description of the release.
• Once you publish the release, confirm the release build completes successfully and the new release is available on the market. Make sure that the document has new entry with id: medic:medic:<major>.<minor>.<patch>
• Upgrade the demo instance to the newly released version.
• Use cht-conf to upload the configuration from the cht-core/config/demo folder to the demo-cht.dev server.
• Announce the release on the CHT Forum, under the "Announcements - Releases" category using this template.
• Go over the list of commits and individually notify contributing / interested community members about the release.
• Mark this issue "done" and close the Milestone.