Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 3.10.2 #6857

Closed
12 tasks done
dianabarsan opened this issue Jan 20, 2021 · 0 comments
Closed
12 tasks done

Release 3.10.2 #6857

dianabarsan opened this issue Jan 20, 2021 · 0 comments
Assignees
Labels
Type: Internal process An organizational process, eg: doing a release
Projects

Comments

@dianabarsan
Copy link
Member

dianabarsan commented Jan 20, 2021

Planning

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.

  • Set the version number in package.json and package-lock.json and submit a PR to the release branch. The easiest way to do this is to use npm --no-git-tag-version version patch.
  • 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 and backported to the release branch release testing can begin.

  • 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.
  • 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.
  • Until release testing passes, make sure regressions are fixed in master, cherry-pick them into the release branch, and release another beta.
  • 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.
  • 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>
  • Announce the release in #products using this template:
@channel *Announcing the release of {{version}}*

This release fixes {{number of bugs}}. Read the release notes for full details: {{url}}
  • Announce the release on the CHT forum, under the "Product - Releases" category. You can use the previous message and omit @channel.
  • Mark this issue "done" and close the project.
@dianabarsan dianabarsan added the Type: Internal process An organizational process, eg: doing a release label Jan 20, 2021
@dianabarsan dianabarsan self-assigned this Jan 20, 2021
@dianabarsan dianabarsan added this to Dev in progress in 3.10.2 Jan 20, 2021
@craig-landry craig-landry linked a pull request Jan 21, 2021 that will close this issue
@dianabarsan dianabarsan removed a link to a pull request Jan 25, 2021
garethbowen pushed a commit that referenced this issue Jan 26, 2021
@dianabarsan dianabarsan moved this from Dev in progress to Done in 3.10.2 Jan 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Internal process An organizational process, eg: doing a release
Projects
No open projects
Development

No branches or pull requests

2 participants