docs: changes based on review
This commit is contained in:
Jacob Groundwater
parent
07a5d7957b
commit
1bce00545d
6 changed files with 20 additions and 13 deletions
|
|
@ -35,7 +35,7 @@ npm install electron --save-dev --save-exact
|
|||
|
||||
The `--save-exact` flag is recommended as Electron does not follow semantic
|
||||
versioning. For info on how to manage Electron versions in your apps, see
|
||||
[Electron versioning](https://electronjs.org/docs/tutorial/electron-versioning).
|
||||
[Electron versioning](https://electronjs.org/docs/tutorial/versioning).
|
||||
|
||||
For more installation options and troubleshooting tips, see
|
||||
[installation](https://electronjs.org/docs/tutorial/installation).
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ an issue:
|
|||
* [Glossary of Terms](glossary.md)
|
||||
* [Supported Platforms](tutorial/supported-platforms.md)
|
||||
* [Security](tutorial/security.md)
|
||||
* [Versioning](versioning.md)
|
||||
* [Versioning](tutorial/versioning.md)
|
||||
* [Application Distribution](tutorial/application-distribution.md)
|
||||
* [Mac App Store Submission Guide](tutorial/mac-app-store-submission-guide.md)
|
||||
* [Windows Store Guide](tutorial/windows-store-guide.md)
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ This document describes the process for releasing a new version of Electron.
|
|||
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](../versioning.md#semver) for more information.
|
||||
[Version Change Rules](../tutorial/versioning.md#semver) for more information.
|
||||
|
||||
## Run the prepare-release script
|
||||
The prepare release script will do the following:
|
||||
|
|
@ -206,7 +206,7 @@ release to npm.
|
|||
|
||||
[the releases page]: https://github.com/electron/electron/releases
|
||||
[this bump commit]: https://github.com/electron/electron/commit/78ec1b8f89b3886b856377a1756a51617bc33f5a
|
||||
[versioning]: /docs/versioning.md
|
||||
[versioning]: /docs/tutorial/versioning.md
|
||||
|
||||
## Fix missing binaries of a release manually
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ In Electron, Node.js and Chromium share a single V8 instance—usually the versi
|
|||
|
||||
### Versioning
|
||||
|
||||
Due to the hard dependency on Node.js and Chromium, Electron is in a tricky versioning position and [does not follow `semver`](http://semver.org). You should therefore always reference a specific version of Electron. [Read more about Electron's versioning](https://electronjs.org/docs/tutorial/electron-versioning) or see the [versions currently in use](https://electronjs.org/#electron-versions).
|
||||
Due to the hard dependency on Node.js and Chromium, Electron is in a tricky versioning position and [does not follow `semver`](http://semver.org). You should therefore always reference a specific version of Electron. [Read more about Electron's versioning](https://electronjs.org/docs/tutorial/versioning) or see the [versions currently in use](https://electronjs.org/#electron-versions).
|
||||
|
||||
### LTS
|
||||
|
||||
|
|
|
|||
7
docs/tutorial/electron-versioning.md
Normal file
7
docs/tutorial/electron-versioning.md
Normal file
|
|
@ -0,0 +1,7 @@
|
|||
Moved to [Versioning](versioning.md)
|
||||
|
||||
<!--
|
||||
|
||||
This file will eventually be removed
|
||||
|
||||
-->
|
||||
|
|
@ -17,7 +17,7 @@ Electron versions *< 2.0* have not conformed to the [semver](http://semver.org)
|
|||
|
||||
Here is an example of the 1.x strategy:
|
||||
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -57,12 +57,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 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.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
|
@ -102,17 +102,17 @@ For each major and minor bump, you should expect too see something like the foll
|
|||
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 bug fix comes into master that can be pack-ported to the release branch. The patch is applied, and a new beta is published as `2.0.0-beta.2`.
|
||||
|
||||
|
||||
* The beta is considered _generally stable_ and it is published again as a non-beta under `2.0.0`.
|
||||
|
||||
|
||||
* Later, a zero-day exploit is revealed and a fix is applied to master. We pack-port the fix to the `2-0-x` line and release `2.0.1`.
|
||||
|
||||
|
||||
|
||||
A few examples of how various semver ranges will pick up new releases:
|
||||
|
||||
|
||||
|
||||
|
||||
# Missing Features: Alphas, and Nightly
|
||||
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.
|
||||
Loading…
Reference in a new issue