Skip to content
This repository has been archived by the owner on Jun 17, 2022. It is now read-only.

Latest commit

 

History

History
105 lines (64 loc) · 6.34 KB

release-process.md

File metadata and controls

105 lines (64 loc) · 6.34 KB
Raw

The process in more detail

Point people: @grabbou, @kelset

Refer to the README for a high-level overview of the process.

NOTE: In these examples the minor version being used is ‘0.42.x’

Initialize the process for a new version

  1. Create the stable branch with the appropriate name:

    git checkout master
git pull
git checkout -b 0.42-stable
git push origin 0.42-stable # your remote alias might be different

  2. Create a new issue on the ‘releases’ repo for the new version and invite users to provide feedback on the RC and what commits [that have landed in master] to cherry-pick. (Hereafter referred to as the RC-issue.)

  3. Ask the contributors involved in the highlights of this version to start preparing a blog-post to accompany the release, in the form of a draft PR against the website-repo.

Publish the release-candidate

  1. Publish the stable branch as an RC. Read more ⇒

  2. Create a GitHub ‘Release’ for the new version and include the highlights of this release, so users might be more motivated to give the RC a try and so they can know what to look out for. Include a link to the RC-issue for people to report issues on. (For subsequent RC releases this copy can simply be copied.)

  3. Ask the point people to generate the CHANGELOG, which makes it easier for users to understand what changes to look out for and/or why they should upgrade sooner rather than later. Ask them to setup a draft PR against this repo; so that it can be iterated upon per each RC and cleaned up over time, so that it's ready for when stable release lands. Read more ⇒

  4. Ask the point people to create the diff for the upgrade helper, which makes it easier for users to know what changes to make to their project when upgrading to this new version. Read more ⇒

Iterate on the release-candidate

  1. First make note of the current CI status, so it can be compared after picking commits.

  2. Take note of all changes that were suggested on the RC-issue and hide those that are not in scope or bring attention to a new problem. Types of changes to include are:

    • Bug-fixes for issues introduced in earlier versions or the new version.
    • Improvements to the overall UX/DX.

  3. Ideally order the commits by date, as that may ease merging.

    ℹ️ You can hover over a relative date in the GitHub UI (e.g. “2 days ago”) to reveal the actual date/time a commit was made.

  4. Cherry-pick those changes that apply cleanly or with minimal effort:

    git cherry-pick [SHA]

  5. Hide all the comments on the RC-issue for changes that have been picked and mark them as resolved.

  6. Leave a comment stating what commits were not picked and for what reason.

  7. If absolutely necessary for expediency, you can make some agreed upon minor fixes directly to the stable branch, but you MUST back-port those to the master branch as soon as possible.

  8. Repeat the process from publishing onward until consensus is reached that the version is good enough to be released as a stable version.

Release stable version

  1. Publish the stable branch as a stable version. Read more ⇒

  2. Close the RC-issue created at the start of this process, lock it as solved, then open a new issue in this repo for the next patch release (patch-release-issue).

  3. Merge the changelog PR to this repo so that it can be referred to in the blogpost & in the Github release.

  4. Merge the blogpost PR to the website-repo in order to publish it.

  5. Create a GitHub ‘Release’ for the stable version and include the highlights of this release, along with links to the changelog, the blogpost and the patch-release-issue (described in the previous points).

  6. Make a PR with the new release of the website documentation by following the steps in their guide, then merge it so it will show show the new version as the currently available version. You can verify that it's defaulting correctly by checking the website-config file.

    • Note: we can afford doing this at the stable release step because because all PRs for the features or fixes landing after the branch has been cut are in hold with Wait on future Release label.

Release subsequent patch versions

After a stable version has landed, keep an eye on the patch-release-issue created; creating a patch release follows the same iterative procedure as release-candidate described above:

  1. Take notes of the comments, and the commits that are requested for cherry picks

  2. Select the ones that are bugfixes or minor improvements (discard any new features/behaviour changing commits - unless there is vast consensus that it's a valid exception)

  3. List the commits, ordered by date, and cherry pick them.

  4. Follow the standard release process to publish the new version as 0.42.1.

  5. Generate new changelog, create a new GH release and ask the maintainers of upgrade-helper to generate new diffs (just like above).

  6. Make a new patch-release-issue issue (closing the old one).