Cht-core: Release 3.9.0

Created on 18 Mar 2020 · 7Comments · Source: medic/cht-core

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] 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. 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] 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.

Internal process

Source

garethbowen

All 7 comments

Upgrade note draft for #6306:

Outbound push's push logic has changed: now each configured outbound push will be sent only once per doc. Specifically: the first time your relevant_to function resolves to true is the first and only time a particular record will be send to a configured external service. This is to ensure that pushes are stable and predictable, and additional pushes are not sent unintentionally or unexpectedly. We are working on allowing for multiple pushes, please see #6419 and contribute your situation to help us determine the best way forward.

@abbyad please read the above (and the linked ticket) and let me know if you think that is well worded for our release notes.

SCdF on 12 May 2020

Looks good, thanks for clarifying.

There is a missing word in the first sentence (outbound push **IS** only sent) and "record / config combination" may be unclear -- perhaps clearer to say that "each configured outbound push will be sent only once per doc."

The rest of the explanation is perfect as is!

abbyad on 12 May 2020

Cool, updated

SCdF on 13 May 2020

We setup a new subcategory on the CHT Forum to announce releases. Can we change the second to last bullet point to say "....under the Product - Releases category."?

https://forum.communityhealthtoolkit.org/c/product/releases/26