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:
Shelley Vohr 2019-04-25 15:14:19 -07:00 committed by GitHub
parent c2c3a04628
commit 2108044bdb
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
10 changed files with 128 additions and 89 deletions

View file

@ -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!

View file

@ -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
```