Skip to content

Latest commit

 

History

History
64 lines (49 loc) · 6.21 KB

releasing.md

File metadata and controls

64 lines (49 loc) · 6.21 KB
Raw

Releasing

Webapp

Planning

  1. Create an organisation wide project. 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.
  2. 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

  1. When development is ready to begin one of the developers should be nominated as a Release Manager, who will be resonsible for making sure the following tasks are completed though not necessarily completing them.
  2. Set the version number in package.json and package-lock.json.
  3. For new major and minor releases update all dependencies that don't have any breaking changes. If there are dependencies with easy to fix breaking changes feel free to fix those too. Raise issues to fix the hard breaking changes.
  4. Write an update in the weekly Product Team call agenda summarising development and acceptance testing progress and identifying any blockers.

Releasing

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

  1. 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!
  1. 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.
  2. Import translations 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>"
  1. 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.
  2. 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 Alix to review it.
  3. Until release testing passes, make sure regressions are fixed in master, cherry-pick them into the release branch, and release another beta.
  4. Export the translations, delete empty translation files and commit to master. Cherry-pick the commit into the release branch.
  5. 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.
  6. 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>
  7. Add the release to the Supported versions and update the EOL date and status of previous releases.
  8. 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
  1. Announce the release on the CHT forum, under the Development category. You can use the previous message and omit @channel.
  2. 🍺

Android apps

All medic Android projects automatically build, sign, and publish builds via Travis. To create a new release:

  1. Determine what version the build will be. This should be a valid semver (eg. v1.1.1). Increment the semver appropriately based on the latest release version:
  2. Tag the commit in master which you'd like to release. Use git tag v1.1.1 with the version from above and then run git push --tags.
  3. Wait for the build to complete. You can monitor the build via travis-ci.org.
  4. To Release via the Google Play Store - Login to the Google Play Console and select the app flavor for release. Navigate to "Release Management > Alpha" and click "Release to Beta". Repeat this for each flavor.
  5. To Side-Load (for Collect and Gateway) - Navigate to the GitHub Releases page (linked above) and download the relevant APKs for distribution.