-
Notifications
You must be signed in to change notification settings - Fork 145
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: add major release line prep doc
- Loading branch information
1 parent
e8fe10d
commit 310100c
Showing
1 changed file
with
57 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,57 @@ | ||
# Major Release Process | ||
|
||
This document outlines the major release stable promotion promotion. | ||
|
||
## Final Beta Release | ||
|
||
One week before stable promotion for a given release line, we should release a final beta with ideally few changes. This means that for a stable release date of Tuesday, we should be releasing a final beta the friday a full > 1 week preceding that Tuesday, to allow for a quiet period week to account for complications. | ||
|
||
Before releasing the final beta, we need to ensure that there remain no unmerged pull requests targeting that branch. This entails two tasks: | ||
|
||
1) Run `/check-unmerged <branch-name>` in Slack and see if any PRs are returned | ||
2) Check open PRs to `master` on `electron/electron` and ensure that none of them carry the label `target/<branch-name>` | ||
|
||
If both tasks are complete, proceed with the final beta release. | ||
|
||
## Communications Preparation | ||
|
||
We need to ensure the following have owners and have been completed: | ||
|
||
1) Blog Post | ||
* This post should contain the following: | ||
* An update for which versions are now supported, and the new types of support for each of those (security-only, etc.) | ||
* Link to timeline for subsequent major release | ||
* A list of breaking changes in the current stable line | ||
* References to any upcoming notable changes or deprecations | ||
2) Tweet - a tweet about the latest stable line & blog post from the official `@electronjs` twitter account | ||
3) Updates to [Supported Versions](https://github.com/electron/electron/blob/master/docs/tutorial/support.md#currently-supported-versions) | ||
4) Timeline for subsequent [major release version](https://electronjs.org/docs/tutorial/electron-timelines) | ||
|
||
## Stable Release Promotion | ||
|
||
The day before the publicly communicated date, we should begin the stable promotion process. This is to account for errors with processes out of our control, like CI errors or errors on npm. | ||
|
||
At approximately noon on that preceding day, a member of the Releases WG should trigger a release with Sudowoodo with the following parameters: | ||
|
||
```sh | ||
Release Branch: Stabilization Line (ie `6-0-x`) | ||
Release Type: `Stable` | ||
``` | ||
|
||
## Immediately Following Release | ||
|
||
Immediately following the release, we need to ensure the following: | ||
|
||
1) The [Electron Website](https://electronjs.org) reflects the latest stabile version | ||
2) The `latest` tag on npm correctly reflects the new major release line | ||
3) The blog post has been successfully published | ||
|
||
## New Stable Preparations | ||
|
||
After a new major line has been officially stabilized, we should begin to prepare for the beta process of the next line. | ||
|
||
For this, we need to ensure the following: | ||
|
||
1) We have a new Node Module Version (NMV) for the line that follows what is about to become the new `master` major. | ||
* If we've just released `v6.0.0`, this means that `7-0-x` is about to become the beta line, and so we would need to procure a NMV for `8-0-x`. | ||
2) Sudowoodo is capable of handling betas for the new major line. |