mirrors/electron
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chore: update versioning doc for nightlies (#15468)

Browse source
This commit is contained in:
Samuel Attard 2018-10-31 04:33:50 +11:00 committed by Shelley Vohr
parent 2bd94293e0
commit 59ee2859a7
1 changed files with 4 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
docs/tutorial/electron-versioning.md
View file

@ -117,12 +117,11 @@ 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, and Nightly # 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.
As a future consideration, we may introduce one or both of the following: As a future consideration, we may introduce one or both of the following:
* nightly builds off of master; these would allow folks to test new features quickly and give feedback
* alpha releases that have looser stability constraints to betas; for example it would be allowable to admit new features while a stability channel is in _alpha_ * alpha releases that have looser stability constraints to betas; for example it would be allowable to admit new features while a stability channel is in _alpha_
# Feature Flags # Feature Flags
@ -143,8 +142,9 @@ We seek to increase clarity at all levels of the update and releases process. St
* We allow squashing of commits, provided that the squashed message adheres the the above message format. * We allow squashing of commits, provided that the squashed message adheres the the above message format.
* It is acceptable for some commits in a pull request to not include a semantic prefix, as long as the pull request title contains a meaningful encompassing semantic message. * It is acceptable for some commits in a pull request to not include a semantic prefix, as long as the pull request title contains a meaningful encompassing semantic message.
# Versionless `master` # Versioned `master`
- The `master` branch will always contain `0.0.0-dev` in its `package.json` - The `master` branch will always contain the next major version `X.0.0-nightly.DATE` in its `package.json`
- Release branches are never merged back to master - Release branches are never merged back to master
- Release branches _do_ contain the correct version in their `package.json` - Release branches _do_ contain the correct version in their `package.json`
- As soon as a release branch is cut for a major, master must be bumped to the next major. I.e. `master` is always versioned as the next theoretical release branch