fix: revert to previous documentation folder structure (#18127)

This commit is contained in:
Michelle Tilley 2019-05-02 15:17:17 -07:00 committed by GitHub
parent c278043511
commit 4808f30538
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
8 changed files with 19 additions and 19 deletions

View file

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

View file

@ -1,6 +1,6 @@
# API Contract # API Contract
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. 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.
## `FIXME` comments ## `FIXME` comments

View file

@ -24,7 +24,7 @@ contribute:
## Asking for General Help ## Asking for General Help
["Finding Support"](../support.md#finding-support) has a ["Finding Support"](../tutorial/support.md#finding-support) has a
list of resources for getting programming help, reporting security issues, list of resources for getting programming help, reporting security issues,
contributing, and more. Please use the issue tracker for bugs only! contributing, and more. Please use the issue tracker for bugs only!

View file

@ -30,7 +30,7 @@ As of version 2.0 Electron [follows `semver`](https://semver.org).
For most applications, and using any recent version of npm, For most applications, and using any recent version of npm,
running `$ npm install electron` will do the right thing. 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 ### LTS

View file

@ -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: 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. 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. 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`. 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. 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. 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: 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`. * 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`. * 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`. * 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`. * 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: 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 # 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. 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.

View file

@ -3,7 +3,7 @@
## Finding Support ## Finding Support
If you have a security concern, 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, If you're looking for programming help,
for answers to questions, for answers to questions,
@ -22,10 +22,10 @@ forums
- [`electron-pl`](https://electronpl.github.io) *(Poland)* - [`electron-pl`](https://electronpl.github.io) *(Poland)*
If you'd like to contribute to Electron, 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, 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) [awesome-electron](https://github.com/sindresorhus/awesome-electron)
is a community-maintained list of useful example apps, is a community-maintained list of useful example apps,