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

update versioning doc

Browse source
This commit is contained in:
Zeke Sikelianos 2017-03-10 08:08:23 -08:00
parent 85d66d2413
commit 7fefb75de5
1 changed files with 45 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1,21 +1,51 @@
# Electron Versioning
If you are a seasoned Node developer, you are surely aware of `semver` - and
might be used to giving your dependency management systems only rough guidelines
rather than fixed version numbers. Due to the hard dependency on Node and
Chromium, Electron is in a slightly more difficult position and does not follow
semver. You should therefore always reference a specific version of Electron.
If you've been using Node and npm for a while, you are probably aware of [Semantic Versioning], or SemVer for short. It's a convention for specifying version numbers for software that helps communicate intentions to the users of your software.
Version numbers are bumped using the following rules:
## Overview of Semantic Versioning
* Major: For breaking changes in Electron's API - if you upgrade from `0.37.0`
to `1.0.0`, you will have to update your app.
* Minor: For major Chrome and minor Node upgrades; or significant Electron
changes - if you upgrade from `1.0.0` to `1.1.0`, your app is supposed to
Semantic versions are always made up of three numbers:
```
major.minor.patch
```
Semantic version numbers are bumped (incremented) using the following rules:
* **Major** is for changes that break backwards compatibility.
* **Minor** is for new features that don't break backwards compatibility.
* **Patch** is for bug fixes and other minor changes.
A simple mnemonic for remembering this scheme is as follows:
```
breaking.feature.fix
```
## Electron Versioning
Due to its dependency on Node and Chromium, it is not possible for the Electron
project to adhere to a SemVer policy. **You should therefore always
reference a specific version of Electron.**
Electron version numbers are bumped using the following rules:
* **Major** is for breaking changes in Electron's API. If you upgrade from `0.37.0`
to `1.0.0`, you will have to make changes to your app.
* **Minor** is for major Chrome and minor Node upgrades, or significant Electron
changes. If you upgrade from `1.5.0` to `1.6.0`, your app is supposed to
still work, but you might have to work around small changes.
* Patch: For new features and bug fixes - if you upgrade from `1.0.0` to
`1.0.1`, your app will continue to work as-is.
* **Patch** is for new features and bug fixes. If you upgrade from `1.6.2` to
`1.6.3`, your app will continue to work as-is.
If you are using `electron` or `electron-prebuilt`, we recommend that you set a fixed version
number (`1.1.0` instead of `^1.1.0`) to ensure that all upgrades of Electron are
a manual operation made by you, the developer.
We recommend that you set a fixed version when installing Electron from npm:
```sh
npm install electron --save-exact --save-dev
```
The `--save-exact` flag will add `electron` to your `package.json` file without
using a `^` or `~`, e.g. `1.6.2` instead of `^1.6.2`. This practice ensures that
all upgrades of Electron are a manual operation made by you, the developer.
[Semantic Versioning](http://semver.org)