Update the documentation on the release process to reflect the new versioning policy.
This commit is contained in:
Vanessa Yuen
parent
7062a6e55d
commit
31eb83223b
1 changed files with 45 additions and 62 deletions
|
|
@ -2,25 +2,15 @@
|
|||
|
||||
This document describes the process for releasing a new version of Electron.
|
||||
|
||||
## Create a backport branch
|
||||
|
||||
If you're about release a new major or minor version of Electron like `1.8.0`,
|
||||
`1.9.0`, or `2.0.0`, first create a branch from the most recent minor release
|
||||
for later backports:
|
||||
|
||||
Assuming you're about to publish `1.8.0`, and the highest `1.7` release was
|
||||
`1.7.6`:
|
||||
|
||||
```sh
|
||||
git checkout -b 1-7-x v1.7.6
|
||||
git push origin HEAD
|
||||
```
|
||||
## Find out what version change is needed
|
||||
Is this a major, minor, patch, or beta version change? Read the [Version Change Rules](docs/tutorial/electron-versioning.md#version-change-rules) to find out.
|
||||
|
||||
## Create a temporary branch
|
||||
|
||||
Create a new branch from `master`. Name it `release` or anything you like.
|
||||
- **If releasing beta,** create a new branch from `master`.
|
||||
- **If releasing a stable version,** create a new branch from the beta branch you're stablizing.
|
||||
|
||||
Note: If you are creating a backport release, you'll check out `1-6-x`, `1-7-x`, etc instead of `master`.
|
||||
Name the new branch `release` or anything you like.
|
||||
|
||||
```sh
|
||||
git checkout master
|
||||
|
|
@ -54,8 +44,6 @@ git push origin HEAD
|
|||
|
||||
This will bump the version number in several files. See [this bump commit] for an example.
|
||||
|
||||
Most releases will be `patch` level. Upgrades to Chrome or other major changes should use `minor`. For more info, see [electron-versioning].
|
||||
|
||||
## Wait for builds :hourglass_flowing_sand:
|
||||
|
||||
The presence of the word [`Bump`](https://github.com/electron/electron/blob/7961a97d7ddbed657c6c867cc8426e02c236c077/script/cibuild-linux#L3-L6) in the commit message created by the `bump-version` script
|
||||
|
|
@ -73,7 +61,6 @@ Writing release notes is a good way to keep yourself busy while the builds are r
|
|||
For prior art, see existing releases on [the releases page].
|
||||
|
||||
Tips:
|
||||
|
||||
- Each listed item should reference a PR on electron/electron, not an issue, nor a PR from another repo like libcc.
|
||||
- No need to use link markup when referencing PRs. Strings like `#123` will automatically be converted to links on github.com.
|
||||
- To see the version of Chromium, V8, and Node in every version of Electron, visit [atom.io/download/electron/index.json](https://atom.io/download/electron/index.json).
|
||||
|
|
@ -98,6 +85,16 @@ For a `patch` release, use the following format:
|
|||
### Windows
|
||||
|
||||
* Fixed a Windows thing. #1234
|
||||
```
|
||||
|
||||
### Minor releases
|
||||
|
||||
For a `minor` release, e.g. `1.8.0`, use this format:
|
||||
|
||||
```
|
||||
## Upgrades
|
||||
|
||||
- Upgraded from Node `oldVersion` to `newVersion`. #123
|
||||
|
||||
## API Changes
|
||||
|
||||
|
|
@ -116,33 +113,50 @@ For a `patch` release, use the following format:
|
|||
* Changed a Windows thing. #123
|
||||
```
|
||||
|
||||
### Minor releases
|
||||
|
||||
For a `minor` release (which is normally a Chromium update, and possibly also a Node update), e.g. `1.8.0`, use this format:
|
||||
|
||||
### Major releases
|
||||
```
|
||||
**Note:** This is a beta release. This is the first release running on upgraded versions of Chrome/Node.js/V8 and most likely will have have some instability and/or regressions.
|
||||
|
||||
Please file new issues for any bugs you find in it.
|
||||
|
||||
This release is published to [npm](https://www.npmjs.com/package/electron) under the `beta` tag and can be installed via `npm install electron@beta`.
|
||||
|
||||
## Upgrades
|
||||
|
||||
- Upgraded from Chrome `oldVersion` to `newVersion`. #123
|
||||
- Upgraded from Chromium `oldVersion` to `newVersion`. #123
|
||||
- Upgraded from Node `oldVersion` to `newVersion`. #123
|
||||
- Upgraded from v8 `oldVersion` to `newVersion`. #9116
|
||||
|
||||
## Breaking API changes
|
||||
|
||||
* Changed a thing. #123
|
||||
|
||||
### Linux
|
||||
|
||||
* Changed a Linux thing. #123
|
||||
|
||||
### macOS
|
||||
|
||||
* Changed a macOS thing. #123
|
||||
|
||||
### Windows
|
||||
|
||||
* Changed a Windows thing. #123
|
||||
|
||||
## Other Changes
|
||||
|
||||
- Some other change. #123
|
||||
```
|
||||
|
||||
### Beta releases
|
||||
Use the same formats as the ones suggested above, but add the following note at the beginning of the changelog:
|
||||
```
|
||||
**Note:** This is a beta release and most likely will have have some instability and/or regressions.
|
||||
|
||||
Please file new issues for any bugs you find in it.
|
||||
|
||||
This release is published to [npm](https://www.npmjs.com/package/electron) under the `beta` tag and can be installed via `npm install electron@beta`.
|
||||
```
|
||||
|
||||
|
||||
## Edit the release draft
|
||||
|
||||
1. Visit [the releases page] and you'll see a new draft release with placeholder release notes.
|
||||
1. Edit the release and add release notes.
|
||||
1. Ensure the `prerelease` checkbox is checked. This should happen automatically for Electron versions >=1.7
|
||||
1. Uncheck the `prerelease` checkbox if you're publishing a stable release; leave it checked for beta releases.
|
||||
1. Click 'Save draft'. **Do not click 'Publish release'!**
|
||||
1. Wait for all builds to pass before proceeding.
|
||||
|
||||
|
|
@ -209,37 +223,6 @@ git push origin :release # delete remote branch
|
|||
[this bump commit]: https://github.com/electron/electron/commit/78ec1b8f89b3886b856377a1756a51617bc33f5a
|
||||
[electron-versioning]: /docs/tutorial/electron-versioning.md
|
||||
|
||||
## Promote a release on npm
|
||||
|
||||
New releases are published to npm with the `beta` tag. Every release should
|
||||
eventually get promoted to stable unless there's a good reason not to.
|
||||
|
||||
Releases are normally given around two weeks in the wild before being promoted.
|
||||
Before promoting a release, check to see if there are any bug reports
|
||||
against that version, e.g. issues labeled with `version/1.7.x`.
|
||||
|
||||
It's also good to ask users in Slack if they're using the beta versions successfully.
|
||||
|
||||
To see what's beta and stable at any given time:
|
||||
|
||||
```
|
||||
$ npm dist-tag ls electron
|
||||
beta: 1.7.5
|
||||
latest: 1.6.11
|
||||
```
|
||||
|
||||
To promote a beta version to stable (aka `latest`):
|
||||
|
||||
```
|
||||
npm dist-tag add electron@1.2.3 latest
|
||||
```
|
||||
|
||||
Then edit the release on GitGub:
|
||||
|
||||
1. Remove `beta` from the release name: electron v1.7.5 ~~beta~~
|
||||
1. Uncheck the `prerelease` checkbox.
|
||||
1. Click "Update release"
|
||||
|
||||
## Fix missing binaries of a release manually
|
||||
|
||||
In the case of a corrupted release with broken CI machines, we might have to
|
||||
|
|
|
|||
Loading…
Reference in a new issue