Browse Source

docs: move organizational info docs to new directory (#17865)

* docs: move organizational info docs to new directory

* fix some markdown lint issues
Shelley Vohr 6 years ago
parent
commit
2108044bdb

+ 5 - 5
docs/README.md

@@ -62,7 +62,7 @@ an issue:
 * Packaging
   * [Code Signing](tutorial/code-signing.md)
 * [Distribution](tutorial/application-distribution.md)
-  * [Support](tutorial/support.md)
+  * [Support](support.md)
   * [Mac App Store](tutorial/mac-app-store-submission-guide.md)
   * [Windows Store](tutorial/windows-store-guide.md)
   * [Snapcraft](tutorial/snapcraft.md)
@@ -84,10 +84,10 @@ These individual tutorials expand on topics discussed in the guide above.
   * [Proxies](tutorial/installation.md#proxies)
   * [Custom Mirrors and Caches](tutorial/installation.md#custom-mirrors-and-caches)
   * [Troubleshooting](tutorial/installation.md#troubleshooting)
-* [In Detail: Electron's Versioning Scheme](tutorial/electron-versioning.md)
-  * [semver](tutorial/electron-versioning.md#semver)
-  * [Stabilization Branches](tutorial/electron-versioning.md#stabilization-branches)
-  * [Beta Releases and Bug Fixes](tutorial/electron-versioning.md#beta-releases-and-bug-fixes)
+* [In Detail: Electron's Versioning Scheme](electron-versioning.md)
+  * [semver](electron-versioning.md#semver)
+  * [Stabilization Branches](electron-versioning.md#stabilization-branches)
+  * [Beta Releases and Bug Fixes](electron-versioning.md#beta-releases-and-bug-fixes)
 * [In Detail: Packaging App Source Code with asar](tutorial/application-packaging.md)
   * [Generating asar Archives](tutorial/application-packaging.md#generating-asar-archives)
   * [Using asar Archives](tutorial/application-packaging.md#using-asar-archives)

+ 43 - 44
docs/api/breaking-changes.md

@@ -1,14 +1,14 @@
 # API Contract
 
-Breaking changes will be documented here, and deprecation warnings added to JS code where possible, at least [one major version](../tutorial/electron-versioning.md#semver) before the change is made.
+Breaking changes will be documented here, and deprecation warnings added to JS code where possible, at least [one major version](../electron-versioning.md#semver) before the change is made.
 
-# `FIXME` comments
+## `FIXME` comments
 
 The `FIXME` string is used in code comments to denote things that should be fixed for future releases. See https://github.com/electron/electron/search?q=fixme
 
-# Planned Breaking API Changes (6.0)
+## Planned Breaking API Changes (6.0)
 
-## `win.setMenu(null)`
+### `win.setMenu(null)`
 
 ```js
 // Deprecated
@@ -17,7 +17,7 @@ win.setMenu(null)
 win.removeMenu()
 ```
 
-## `contentTracing.getTraceBufferUsage()`
+### `contentTracing.getTraceBufferUsage()`
 
 ```js
 // Deprecated
@@ -30,7 +30,7 @@ contentTracing.getTraceBufferUsage().then(infoObject => {
 })
 ```
 
-## `electron.screen` in renderer process
+### `electron.screen` in renderer process
 
 ```js
 // Deprecated
@@ -39,7 +39,7 @@ require('electron').screen
 require('electron').remote.screen
 ```
 
-## `require` in sandboxed renderers
+### `require` in sandboxed renderers
 
 ```js
 // Deprecated
@@ -63,7 +63,7 @@ require('path')
 require('electron').remote.require('path')
 ```
 
-## `powerMonitor.querySystemIdleState`
+### `powerMonitor.querySystemIdleState`
 
 ```js
 // Deprecated
@@ -72,7 +72,7 @@ powerMonitor.querySystemIdleState(threshold, callback)
 const idleState = getSystemIdleState(threshold)
 ```
 
-## `powerMonitor.querySystemIdleTime`
+### `powerMonitor.querySystemIdleTime`
 
 ```js
 // Deprecated
@@ -90,13 +90,13 @@ app.enableMixedSandbox()
 
 Mixed-sandbox mode is now enabled by default.
 
-## Preload scripts outside of app path are not allowed
+### Preload scripts outside of app path are not allowed
 
 For security reasons, preload scripts can only be loaded from a subpath of the [app path](app.md#appgetapppath).
 
-# Planned Breaking API Changes (5.0)
+## Planned Breaking API Changes (5.0)
 
-## `new BrowserWindow({ webPreferences })`
+### `new BrowserWindow({ webPreferences })`
 
 The following `webPreferences` option default values are deprecated in favor of the new defaults listed below.
 
@@ -106,16 +106,16 @@ The following `webPreferences` option default values are deprecated in favor of
 | `nodeIntegration` | `true` | `false` |
 | `webviewTag` | `nodeIntegration` if set else `true` | `false` |
 
-## `nativeWindowOpen`
+### `nativeWindowOpen`
 
 Child windows opened with the `nativeWindowOpen` option will always have Node.js integration disabled.
 
-## Privileged Schemes Registration
+### Privileged Schemes Registration
 
 Renderer process APIs `webFrame.setRegisterURLSchemeAsPrivileged` and `webFrame.registerURLSchemeAsBypassingCSP` as well as browser process API `protocol.registerStandardSchemes` have been removed.
 A new API, `protocol.registerSchemesAsPrivileged` has been added and should be used for registering custom schemes with the required privileges. Custom schemes are required to be registered before app ready.
 
-## webFrame Isolated World APIs
+### webFrame Isolated World APIs
 
 ```js
 // Deprecated
@@ -132,11 +132,11 @@ webFrame.setIsolatedWorldInfo(
   })
 ```
 
-# Planned Breaking API Changes (4.0)
+## Planned Breaking API Changes (4.0)
 
 The following list includes the breaking API changes made in Electron 4.0.
 
-## `app.makeSingleInstance`
+### `app.makeSingleInstance`
 
 ```js
 // Deprecated
@@ -150,7 +150,7 @@ app.on('second-instance', (event, argv, cwd) => {
 })
 ```
 
-## `app.releaseSingleInstance`
+### `app.releaseSingleInstance`
 
 ```js
 // Deprecated
@@ -159,7 +159,7 @@ app.releaseSingleInstance()
 app.releaseSingleInstanceLock()
 ```
 
-## `app.getGPUInfo`
+### `app.getGPUInfo`
 
 ```js
 app.getGPUInfo('complete')
@@ -167,7 +167,7 @@ app.getGPUInfo('complete')
 app.getGPUInfo('basic')
 ```
 
-## `win_delay_load_hook`
+### `win_delay_load_hook`
 
 When building native modules for windows, the `win_delay_load_hook` variable in
 the module's `binding.gyp` must be true (which is the default). If this hook is
@@ -175,11 +175,11 @@ not present, then the native module will fail to load on Windows, with an error
 message like `Cannot find module`. See the [native module
 guide](/docs/tutorial/using-native-node-modules.md) for more.
 
-# Breaking API Changes (3.0)
+## Breaking API Changes (3.0)
 
 The following list includes the breaking API changes in Electron 3.0.
 
-## `app`
+### `app`
 
 ```js
 // Deprecated
@@ -192,7 +192,7 @@ const metrics = app.getAppMetrics()
 const { memory } = metrics[0] // Deprecated property
 ```
 
-## `BrowserWindow`
+### `BrowserWindow`
 
 ```js
 // Deprecated
@@ -216,7 +216,7 @@ window.on('app-command', (e, cmd) => {
 })
 ```
 
-## `clipboard`
+### `clipboard`
 
 ```js
 // Deprecated
@@ -240,7 +240,7 @@ clipboard.writeHtml()
 clipboard.writeHTML()
 ```
 
-## `crashReporter`
+### `crashReporter`
 
 ```js
 // Deprecated
@@ -257,7 +257,7 @@ crashReporter.start({
 })
 ```
 
-## `nativeImage`
+### `nativeImage`
 
 ```js
 // Deprecated
@@ -268,14 +268,14 @@ nativeImage.createFromBuffer(buffer, {
 })
 ```
 
-## `process`
+### `process`
 
 ```js
 // Deprecated
 const info = process.getProcessMemoryInfo()
 ```
 
-## `screen`
+### `screen`
 
 ```js
 // Deprecated
@@ -284,7 +284,7 @@ screen.getMenuBarHeight()
 screen.getPrimaryDisplay().workArea
 ```
 
-## `session`
+### `session`
 
 ```js
 // Deprecated
@@ -297,7 +297,7 @@ ses.setCertificateVerifyProc((request, callback) => {
 })
 ```
 
-## `Tray`
+### `Tray`
 
 ```js
 // Deprecated
@@ -311,7 +311,7 @@ tray.setHighlightMode(false)
 tray.setHighlightMode('off')
 ```
 
-## `webContents`
+### `webContents`
 
 ```js
 // Deprecated
@@ -324,7 +324,7 @@ webContents.setSize(options)
 // There is no replacement for this API
 ```
 
-## `webFrame`
+### `webFrame`
 
 ```js
 // Deprecated
@@ -338,7 +338,7 @@ webFrame.registerURLSchemeAsPrivileged('app', { secure: true })
 protocol.registerStandardSchemes(['app'], { secure: true })
 ```
 
-## `<webview>`
+### `<webview>`
 
 ```js
 // Removed
@@ -354,7 +354,7 @@ webview.onkeydown = () => { /* handler */ }
 webview.onkeyup = () => { /* handler */ }
 ```
 
-## Node Headers URL
+### Node Headers URL
 
 This is the URL specified as `disturl` in a `.npmrc` file or as the `--dist-url`
 command line flag when building native Node modules.
@@ -363,12 +363,11 @@ Deprecated: https://atom.io/download/atom-shell
 
 Replace with: https://atom.io/download/electron
 
-
-# Breaking API Changes (2.0)
+## Breaking API Changes (2.0)
 
 The following list includes the breaking API changes made in Electron 2.0.
 
-## `BrowserWindow`
+### `BrowserWindow`
 
 ```js
 // Deprecated
@@ -379,7 +378,7 @@ let optionsB = { titleBarStyle: 'hiddenInset' }
 let windowB = new BrowserWindow(optionsB)
 ```
 
-## `menu`
+### `menu`
 
 ```js
 // Removed
@@ -388,7 +387,7 @@ menu.popup(browserWindow, 100, 200, 2)
 menu.popup(browserWindow, { x: 100, y: 200, positioningItem: 2 })
 ```
 
-## `nativeImage`
+### `nativeImage`
 
 ```js
 // Removed
@@ -402,13 +401,13 @@ nativeImage.toJpeg()
 nativeImage.toJPEG()
 ```
 
-## `process`
+### `process`
 
 * `process.versions.electron` and `process.version.chrome` will be made
   read-only properties for consistency with the other `process.versions`
   properties set by Node.
 
-## `webContents`
+### `webContents`
 
 ```js
 // Removed
@@ -417,7 +416,7 @@ webContents.setZoomLevelLimits(1, 2)
 webContents.setVisualZoomLevelLimits(1, 2)
 ```
 
-## `webFrame`
+### `webFrame`
 
 ```js
 // Removed
@@ -426,7 +425,7 @@ webFrame.setZoomLevelLimits(1, 2)
 webFrame.setVisualZoomLevelLimits(1, 2)
 ```
 
-## `<webview>`
+### `<webview>`
 
 ```js
 // Removed
@@ -435,7 +434,7 @@ webview.setZoomLevelLimits(1, 2)
 webview.setVisualZoomLevelLimits(1, 2)
 ```
 
-## Duplicate ARM Assets
+### Duplicate ARM Assets
 
 Each Electron release includes two identical ARM builds with slightly different
 filenames, like `electron-v1.7.3-linux-arm.zip` and

+ 0 - 0
docs/tutorial/app-feedback-program.md → docs/app-feedback-program.md


+ 1 - 3
docs/development/issues.md

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

+ 54 - 22
docs/development/releasing.md

@@ -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) [email protected]
 ```
 
 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 [email protected] latest
+npm dist-tag add [email protected] latest
 ```
 
 [the releases page]: https://github.com/electron/electron/releases
@@ -284,25 +312,29 @@ $ npm dist-tag add [email protected] 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
 ```

+ 13 - 1
docs/tutorial/electron-timelines.md → docs/electron-timelines.md

@@ -1,5 +1,11 @@
 # Electron Release Timelines
-### Notes:
+
+## 5.0.0 Release Schedule
+
+Take a look at 5.0.0 Timeline [blog post](https://electronjs.org/blog/electron-5-0-timeline) for info about publicizing our release dates.
+
+### Notes
+
 - These dates are our goals but there may be reasons for adjusting the stable deadline, such as security bugs.
 - These are our scheduled beta releases, however we often release more betas than scheduled.
 
@@ -26,6 +32,12 @@ Take a look at 5.0.0 Timeline [blog post](https://electronjs.org/blog/electron-5
 *Includes: Chromium M73 and Node v12.0*
 
 ## 6.0.0 Release Schedule
+
+### Notes
+
+- These dates are our goals but there may be reasons for adjusting the stable deadline, such as security bugs.
+- These are our scheduled beta releases, however we often release more betas than scheduled.
+
 | Date/Week Of    | Release      | Comments       |
 | --------------- | ------------ | -------------- |
 | Thu, 2019-Apr-25 | 6.0.0-beta.1 | 🔥 |

+ 8 - 8
docs/tutorial/electron-versioning.md → docs/electron-versioning.md

@@ -20,7 +20,7 @@ Electron versions *< 2.0* did not conform to the [semver](http://semver.org) spe
 
 Here is an example of the 1.x strategy:
 
-![](../images/versioning-sketch-0.png)
+![](images/versioning-sketch-0.png)
 
 An app developed with `1.8.1` cannot take the `1.8.3` bug fix without either absorbing the `1.8.2` feature, or by backporting the fix and maintaining a new release line.
 
@@ -55,12 +55,12 @@ Note that most Chromium updates will be considered breaking. Fixes that can be b
 
 Stabilization branches are branches that run parallel to master, taking in only cherry-picked commits that are related to security or stability. These branches are never merged back to master.
 
-![](../images/versioning-sketch-1.png)
+![](images/versioning-sketch-1.png)
 
 Stabilization branches are always either **major** or **minor** version lines, and named against the following template `$MAJOR-$MINOR-x` e.g. `2-0-x`.
 
 We allow for multiple stabilization branches to exist simultaneously, and intend to support at least two in parallel at all times, backporting security fixes as necessary.
-![](../images/versioning-sketch-2.png)
+![](images/versioning-sketch-2.png)
 
 Older lines will not be supported by GitHub, but other groups can take ownership and backport stability and security fixes on their own. We discourage this, but recognize that it makes life easier for many app developers.
 
@@ -105,17 +105,17 @@ For each major and minor bump, you should expect to see something like the follo
 An example lifecycle in pictures:
 
 * A new release branch is created that includes the latest set of features. It is published as `2.0.0-beta.1`.
-![](../images/versioning-sketch-3.png)
+![](images/versioning-sketch-3.png)
 * A bug fix comes into master that can be backported to the release branch. The patch is applied, and a new beta is published as `2.0.0-beta.2`.
-![](../images/versioning-sketch-4.png)
+![](images/versioning-sketch-4.png)
 * The beta is considered _generally stable_ and it is published again as a non-beta under `2.0.0`.
-![](../images/versioning-sketch-5.png)
+![](images/versioning-sketch-5.png)
 * Later, a zero-day exploit is revealed and a fix is applied to master. We backport the fix to the `2-0-x` line and release `2.0.1`.
-![](../images/versioning-sketch-6.png)
+![](images/versioning-sketch-6.png)
 
 A few examples of how various semver ranges will pick up new releases:
 
-![](../images/versioning-sketch-7.png)
+![](images/versioning-sketch-7.png)
 
 # Missing Features: Alphas
 Our strategy has a few tradeoffs, which for now we feel are appropriate. Most importantly that new features in master may take a while before reaching a stable release line. If you want to try a new feature immediately, you will have to build Electron yourself.

+ 3 - 3
docs/tutorial/support.md → docs/support.md

@@ -3,7 +3,7 @@
 ## Finding Support
 
 If you have a security concern,
-please see the [security document](../../SECURITY.md).
+please see the [security document](../SECURITY.md).
 
 If you're looking for programming help,
 for answers to questions,
@@ -22,10 +22,10 @@ forums
 - [`electron-pl`](https://electronpl.github.io) *(Poland)*
 
 If you'd like to contribute to Electron,
-see the [contributing document](../../CONTRIBUTING.md).
+see the [contributing document](../CONTRIBUTING.md).
 
 If you've found a bug in a [supported version](#supported-versions) of Electron,
-please report it with the [issue tracker](../development/issues.md).
+please report it with the [issue tracker](development/issues.md).
 
 [awesome-electron](https://github.com/sindresorhus/awesome-electron)
 is a community-maintained list of useful example apps,

+ 1 - 2
docs/tutorial/about.md

@@ -24,14 +24,13 @@ When a new version of Node.js is released, Electron usually waits about a month
 
 In Electron, Node.js and Chromium share a single V8 instance—usually the version that Chromium is using. Most of the time this _just works_ but sometimes it means patching Node.js.
 
-
 ### Versioning
 
 As of version 2.0 Electron [follows `semver`](https://semver.org).
 For most applications, and using any recent version of npm,
 running `$ npm install electron` will do the right thing.
 
-The version update process is detailed explicitly in our [Versioning Doc](electron-versioning.md).
+The version update process is detailed explicitly in our [Versioning Doc](../electron-versioning.md).
 
 ### LTS
 

+ 0 - 1
docs/tutorial/supported-platforms.md

@@ -1 +0,0 @@
-Moved to [support.md](support.md)