docs: move organizational info docs to new directory (#17865)
* docs: move organizational info docs to new directory * fix some markdown lint issues
This commit is contained in:
parent
c2c3a04628
commit
2108044bdb
10 changed files with 128 additions and 89 deletions
|
@ -1,7 +1,5 @@
|
|||
# Issues In Electron
|
||||
|
||||
# Issues
|
||||
|
||||
* [How to Contribute in Issues](#how-to-contribute-in-issues)
|
||||
* [Asking for General Help](#asking-for-general-help)
|
||||
* [Submitting a Bug Report](#submitting-a-bug-report)
|
||||
|
@ -26,7 +24,7 @@ contribute:
|
|||
|
||||
## Asking for General Help
|
||||
|
||||
["Finding Support"](../tutorial/support.md#finding-support) has a
|
||||
["Finding Support"](../support.md#finding-support) has a
|
||||
list of resources for getting programming help, reporting security issues,
|
||||
contributing, and more. Please use the issue tracker for bugs only!
|
||||
|
||||
|
|
|
@ -3,6 +3,7 @@
|
|||
This document describes the process for releasing a new version of Electron.
|
||||
|
||||
## Set your tokens and environment variables
|
||||
|
||||
You'll need Electron S3 credentials in order to create and
|
||||
upload an Electron release. Contact a team member for more
|
||||
information.
|
||||
|
@ -29,18 +30,18 @@ Once you've generated these tokens, put them in a `.env` file in the root direct
|
|||
of the project. This file is gitignored, and will be loaded into the
|
||||
environment by the release scripts.
|
||||
|
||||
|
||||
## Determine which branch to release from
|
||||
|
||||
- **If releasing beta,** run the scripts below from `master`.
|
||||
- **If releasing a stable version,** run the scripts below from the branch
|
||||
* **If releasing beta,** run the scripts below from `master`.
|
||||
* **If releasing a stable version,** run the scripts below from the branch
|
||||
you're stabilizing.
|
||||
|
||||
## Find out what version change is needed
|
||||
|
||||
Run `npm run prepare-release -- --notesOnly` to view auto generated release
|
||||
notes. The notes generated should help you determine if this is a major, minor,
|
||||
patch, or beta version change. Read the
|
||||
[Version Change Rules](../tutorial/electron-versioning.md#semver) for more information.
|
||||
[Version Change Rules](../electron-versioning.md#semver) for more information.
|
||||
|
||||
**NB:** If releasing from a branch, e.g. 1-8-x, check out the branch with
|
||||
`git checkout 1-8-x` rather than `git checkout -b remotes/origin/1-8-x`.
|
||||
|
@ -48,7 +49,9 @@ The scripts need `git rev-parse --abbrev-ref HEAD` to return a short name,
|
|||
e.g. no `remotes/origin/`
|
||||
|
||||
## Run the prepare-release script
|
||||
|
||||
The prepare release script will do the following:
|
||||
|
||||
1. Check if a release is already in process and if so it will halt.
|
||||
2. Create a release branch.
|
||||
3. Bump the version number in several files. See [this bump commit] for an example.
|
||||
|
@ -58,28 +61,38 @@ The prepare release script will do the following:
|
|||
|
||||
Once you have determined which type of version change is needed, run the
|
||||
`prepare-release` script with arguments according to your need:
|
||||
- `[major|minor|patch|beta]` to increment one of the version numbers, or
|
||||
- `--stable` to indicate this is a stable version
|
||||
|
||||
* `[major|minor|patch|beta]` to increment one of the version numbers, or
|
||||
* `--stable` to indicate this is a stable version
|
||||
|
||||
For example:
|
||||
|
||||
### Major version change
|
||||
|
||||
```sh
|
||||
npm run prepare-release -- major
|
||||
```
|
||||
|
||||
### Minor version change
|
||||
|
||||
```sh
|
||||
npm run prepare-release -- minor
|
||||
```
|
||||
|
||||
### Patch version change
|
||||
|
||||
```sh
|
||||
npm run prepare-release -- patch --stable
|
||||
```
|
||||
|
||||
### Beta version change
|
||||
|
||||
```sh
|
||||
npm run prepare-release -- beta
|
||||
```
|
||||
|
||||
### Promote beta to stable
|
||||
|
||||
```sh
|
||||
npm run prepare-release -- --stable
|
||||
```
|
||||
|
@ -87,19 +100,20 @@ npm run prepare-release -- --stable
|
|||
Tip: You can test the new version number before running `prepare-release` with
|
||||
a dry run of the `bump-version` script with the same major/minor/patch/beta
|
||||
arguments, e.g.:
|
||||
|
||||
```sh
|
||||
$ ./script/bump-version.py --bump minor --dry-run
|
||||
./script/bump-version.py --bump minor --dry-run
|
||||
```
|
||||
|
||||
## Wait for builds :hourglass_flowing_sand:
|
||||
The `prepare-release` script will trigger the builds via API calls.
|
||||
To monitor the build progress, see the following pages:
|
||||
|
||||
- [electron-release-mas-x64](https://github.visualstudio.com/electron/_build/index?context=allDefinitions&path=%5C&definitionId=19&_a=completed) for MAS builds.
|
||||
- [electron-release-osx-x64](https://github.visualstudio.com/electron/_build/index?context=allDefinitions&path=%5C&definitionId=18&_a=completed) for OSX builds.
|
||||
- [circleci.com/gh/electron/electron](https://circleci.com/gh/electron) for Linux builds.
|
||||
- [windows-ci.electronjs.org/project/AppVeyor/electron-39ng6](https://windows-ci.electronjs.org/project/AppVeyor/electron-39ng6) for Windows 32-bit builds.
|
||||
- [windows-ci.electronjs.org/project/AppVeyor/electron](https://windows-ci.electronjs.org/project/AppVeyor/electron) for Windows 64-bit builds.
|
||||
* [electron-release-mas-x64](https://github.visualstudio.com/electron/_build/index?context=allDefinitions&path=%5C&definitionId=19&_a=completed) for MAS builds.
|
||||
* [electron-release-osx-x64](https://github.visualstudio.com/electron/_build/index?context=allDefinitions&path=%5C&definitionId=18&_a=completed) for OSX builds.
|
||||
* [circleci.com/gh/electron/electron](https://circleci.com/gh/electron) for Linux builds.
|
||||
* [windows-ci.electronjs.org/project/AppVeyor/electron-39ng6](https://windows-ci.electronjs.org/project/AppVeyor/electron-39ng6) for Windows 32-bit builds.
|
||||
* [windows-ci.electronjs.org/project/AppVeyor/electron](https://windows-ci.electronjs.org/project/AppVeyor/electron) for Windows 64-bit builds.
|
||||
|
||||
## Compile release notes
|
||||
|
||||
|
@ -107,9 +121,10 @@ 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).
|
||||
|
||||
* 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).
|
||||
|
||||
### Patch releases
|
||||
|
||||
|
@ -160,6 +175,7 @@ For a `minor` release, e.g. `1.8.0`, use this format:
|
|||
```
|
||||
|
||||
### Major releases
|
||||
|
||||
```sh
|
||||
## Upgrades
|
||||
|
||||
|
@ -188,8 +204,10 @@ For a `minor` release, e.g. `1.8.0`, use this format:
|
|||
```
|
||||
|
||||
### Beta releases
|
||||
|
||||
Use the same formats as the ones suggested above, but add the following note at
|
||||
the beginning of the changelog:
|
||||
|
||||
```sh
|
||||
**Note:** This is a beta release and most likely will have have some
|
||||
instability and/or regressions.
|
||||
|
@ -209,9 +227,11 @@ release notes.
|
|||
3. Click 'Save draft'. **Do not click 'Publish release'!**
|
||||
4. Wait for all builds to pass before proceeding.
|
||||
5. In the branch, verify that the release's files have been created:
|
||||
|
||||
```sh
|
||||
$ npm run release -- --validateRelease
|
||||
npm run release -- --validateRelease
|
||||
```
|
||||
|
||||
Note, if you need to run `--validateRelease` more than once to check the assets,
|
||||
run it as above the first time, then `node ./script/release.js --validateRelease`
|
||||
for subsequent calls so that you don't have to rebuild each time you want to
|
||||
|
@ -222,6 +242,7 @@ check the assets.
|
|||
Once the merge has finished successfully, run the `release` script
|
||||
via `npm run release` to finish the release process. This script will do the
|
||||
following:
|
||||
|
||||
1. Build the project to validate that the correct version number is being released.
|
||||
2. Download the binaries and generate the node headers and the .lib linker used
|
||||
on Windows by node-gyp to build native modules.
|
||||
|
@ -236,6 +257,7 @@ the correct checksums as specified in the SHASUMS files.
|
|||
Before publishing to npm, you'll need to log into npm as Electron. Optionally,
|
||||
you may find [npmrc](https://www.npmjs.com/package/npmrc) to be a useful way
|
||||
to keep Electron's profile side-by-side with your own:
|
||||
|
||||
```sh
|
||||
$ sudo npm install -g npmrc
|
||||
$ npmrc -c electron
|
||||
|
@ -245,6 +267,7 @@ Activating .npmrc "electron"
|
|||
|
||||
The Electron account's credentials are kept by GitHub in a password manager.
|
||||
You'll also need to have access to an 2FA authenticator app with the appropriate OTP generator code to log in.
|
||||
|
||||
```sh
|
||||
$ npm login
|
||||
Username: electron-nightly
|
||||
|
@ -253,6 +276,7 @@ Email: (this IS public) electron@github.com
|
|||
```
|
||||
|
||||
Publish the release to npm. Before running this you'll need to have set `ELECTRON_NPM_OTP` as an environment variable using a code from the aforementioned 2FA authenticator app.
|
||||
|
||||
```sh
|
||||
$ npm whoami
|
||||
electron-nightly
|
||||
|
@ -260,18 +284,22 @@ $ npm run publish-to-npm
|
|||
```
|
||||
|
||||
After publishing, you can check the `latest` release:
|
||||
|
||||
```sh
|
||||
$ npm dist-tag ls electron
|
||||
npm dist-tag ls electron
|
||||
```
|
||||
|
||||
If for some reason `npm run publish-to-npm` fails,
|
||||
you can tag the release manually:
|
||||
|
||||
```sh
|
||||
$ npm dist-tag add electron@<version> <tag>
|
||||
npm dist-tag add electron@<version> <tag>
|
||||
```
|
||||
|
||||
e.g.:
|
||||
|
||||
```sh
|
||||
$ npm dist-tag add electron@2.0.0 latest
|
||||
npm dist-tag add electron@2.0.0 latest
|
||||
```
|
||||
|
||||
[the releases page]: https://github.com/electron/electron/releases
|
||||
|
@ -284,25 +312,29 @@ $ npm dist-tag add electron@2.0.0 latest
|
|||
|
||||
If a release build fails for some reason, you can use `script/ci-release-build.js` to rerun a release build:
|
||||
|
||||
### Rerun all linux builds:
|
||||
### Rerun all linux builds
|
||||
|
||||
```sh
|
||||
node script/ci-release-build.js --ci=CircleCI --ghRelease TARGET_BRANCH
|
||||
(TARGET_BRANCH) is the branch you are releasing from.
|
||||
```
|
||||
|
||||
### Rerun all macOS builds:
|
||||
### Rerun all macOS builds
|
||||
|
||||
```sh
|
||||
node script/ci-release-build.js --ci=VSTS --ghRelease TARGET_BRANCH
|
||||
(TARGET_BRANCH) is the branch you are releasing from.
|
||||
```
|
||||
|
||||
### Rerun all Windows builds:
|
||||
### Rerun all Windows builds
|
||||
|
||||
```sh
|
||||
node script/ci-release-build.js --ci=AppVeyor --ghRelease TARGET_BRANCH
|
||||
(TARGET_BRANCH) is the branch you are releasing from.
|
||||
```
|
||||
|
||||
Additionally you can pass a job name to the script to run an individual job, eg:
|
||||
|
||||
```sh
|
||||
node script/ci-release-build.js --ci=AppVeyor --ghRelease --job=electron-x64 TARGET_BRANCH
|
||||
```
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue