Cht-core: Release 3.11.0

[garethbowen]

Planning

• [x] Create an organisation wide project 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 in our case relate to updated software requirements (egs: CouchDB, node, minimum browser versions), broken backwards compatibility in an api, or a major visual update that requires user retraining.
• [x] Add all the issues to be worked on to the project. Ideally each minor release will have one or two features, a handful of improvements, and plenty of bugs.

Development

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

• [x] Set the version number in package.json and package-lock.json and submit a PR. The easiest way to do this is to use npm --no-git-tag-version version <major|minor>.
• [x] Raise a new issue called Update dependencies for <version> with a description that links to the documentation. This should be done early in the release cycle so find a volunteer to take this on and assign it to them.
• [x] Go through all features and improvements scheduled for this release and raise cht-docs issues for product education to be written where appropriate. If in doubt, check with Max.
• [x] Write an update in the weekly Product Team call agenda summarising development and acceptance testing progress and identifying any blockers. The release manager is to update this every week until the version is released.

Releasing

Once all issues have passed acceptance testing and have been merged into master release testing can begin.

• [x] Create a new release branch from master named <major>.<minor>.x in medic. Post a message to #development using this template:

@core_devs I've just created the `<major>.<minor>.x` release branch. Please be aware that any further changes intended for this release will have to be merged to `master` then backported. Thanks!

• [x] Build a beta named <major>.<minor>.<patch>-beta.1 by pushing a git tag and when CI completes successfully notify the QA team that it's ready for release testing.
• [x] [Import translations keys](https://github.com/medic/medic-docs/blob/master/development/translations.md#adding-new-keys) into POE and notify the #translations Slack channel translate new and updated values, for example:

@channel I've just updated the translations in POE. These keys have been added: "<added-list>", and these keys have been updated: "<updated-list>"

• [x] Create a new document in the release-notes folder in master. Ensure all issues are in the GH Project, that they're correct labelled, and have human readable descriptions. Use this script to export the issues into our changelog format. Manually document any known migration steps and known issues. Provide description, screenshots, videos, and anything else to help communicate particularly important changes. Document any required or recommended upgrades to our other products (eg: medic-conf, medic-gateway, medic-android). Assign the PR to a) the Director of Technology, and b) an SRE to review and confirm the documentation on upgrade instructions and breaking changes is sufficient.
• [x] Create a Google Doc in the blog posts folder with the draft of a blog post promoting the release based on the release notes above. Once it's ready ask Max and Kelly to review it.
• [x] Until release testing passes, make sure regressions are fixed in master, cherry-pick them into the release branch, and release another beta.
• [x] [Export the translations](https://github.com/medic/medic-docs/blob/master/development/translations.md#exporting-changes-from-poeditor-to-github), delete empty translation files and commit to master. Cherry-pick the commit into the release branch.
• [x] Create a release in GitHub from the release branch so it shows up under the Releases tab with the naming convention <major>.<minor>.<patch>. This will create the git tag automatically. Link to the release notes in the description of the release.
• [x] 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>
• [x] Upgrade the demo-cht.dev instance to this version.
• [x] Follow the instructions for releasing other products that have been updated in this project (eg: medic-conf, medic-gateway, medic-android).
• [x] Add the release to the Supported versions and update the EOL date and status of previous releases.
• [x] Announce the release in #products and #cht-contributors using this template:

@channel *We're excited to announce the release of {{version}}*

New features include {{key_features}}. We've also implemented loads of other improvements and fixed a heap of bugs.

Read the release notes for full details: {{url}}

Following our support policy, versions {{versions}} are no longer supported. Projects running these versions should start planning to upgrade in the near future. For more details read our software support documentation: https://github.com/medic/medic-docs/blob/master/installation/supported-software.md#supported-versions

To see what's scheduled for the next releases have a read of the product roadmap: https://github.com/orgs/medic/projects?query=is%3Aopen+sort%3Aname-asc

• [x] Announce the release on the CHT forum, under the "Product - Releases" category. You can use the previous message and omit @channel.
• [x] Mark this issue "done" and close the project.

[MaxDiz]

feature documentation for this release: https://github.com/medic/cht-docs/issues/282

[MaxDiz]

missing feature education from v3.10 related to GPS improvements - https://github.com/medic/cht-docs/issues/326

[MaxDiz]

@garethbowen a couple of minor updates to the release tickets:

• the #cht-contributors channel has been deprecated so can be removed
• add a checkbox to update the Documentation page of the forum with short posts for new and improved information on features

[garethbowen]

@MaxDiz For your first point, that has been removed from the template, but this issue was generated before the template was updated.

For your second point, I think this process is getting too long as it is and we risk delaying releases if we add even more steps. I think ideally these posts would be written by the product management team and not the release manager who's usually an engineer. Instead, could we add a checkbox for "raise documentation issues for new features and notify the product manager" or similar?

FYI the issue template is stored in the git repo - please feel free to propose these changes via PR directly to the template by clicking the little pencil icon.

[MaxDiz]

yup, that was a note for product mgmt to write the documentation post. I'll click the 'little pencil' and submit a PR :)

[garethbowen]

NB: Document that the upload image feature is broken as a known issue.

[garethbowen]

For https://github.com/medic/cht-core/pull/6759 mention that...

it is a "useful building block" for anybody wanting to do deployments via GitHub actions including continuous deployment.

Docs: https://github.com/medic/cht-core/tree/master/.github/actions/deploy-with-medic-conf