Merge branch 'master' into felix-notification-docs

docs/tutorial/desktop-environment-integration.md

@@ -8,6 +8,10 @@ applications can put a custom menu in the dock menu.
 This guide explains how to integrate your application into those desktop
 environments with Electron APIs.
 
+## Notifications
+
+See [Notifications](notifications.md)
+
 ## Recent documents (Windows & macOS)
 
 Windows and macOS provide easy access to a list of recent documents opened by

docs/tutorial/electron-versioning.md

@@ -1,21 +1,55 @@
 # 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.
+
+Alternatively, you can use the `~` prefix in your SemVer range, like `~1.6.2`.
+This will lock your major and minor version, but allow new patch versions to
+be installed.
+
+[Semantic Versioning]: http://semver.org

docs/tutorial/windows-store-guide.md

@@ -69,8 +69,7 @@ The output should look roughly like this:
 │   └── atom.asar
 ├── snapshot_blob.bin
 ├── squirrel.exe
-├── ui_resources_200_percent.pak
-└── xinput1_3.dll
+└── ui_resources_200_percent.pak
 ```
 
 ## Step 2: Running electron-windows-store