Skip to content

Latest commit

 

History

History
70 lines (42 loc) · 3.62 KB

release-process.md

File metadata and controls

70 lines (42 loc) · 3.62 KB
Raw

The process in more detail

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

  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.

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. 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. Bump defaultVersionShown in the website’s config so it will show show the new version as the currently available version.