use non-relative image paths to interop with website deploy
Jacob Groundwater
|
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
|
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 34 KiB |
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
|
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 32 KiB |
|
Before Width: | Height: | Size: 33 KiB After Width: | Height: | Size: 33 KiB |
|
Before Width: | Height: | Size: 38 KiB After Width: | Height: | Size: 38 KiB |
|
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 45 KiB |
|
|
@ -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.
|
||||
|
|
|
|||