docs(faq): clarify the versioning stratgey

- When do breaking changes appear
- Semver
- Compatibility of modules

Author: Narretz

docs/content/misc/faq.ngdoc

@@ -25,10 +25,47 @@ So it's definitely not a plugin or some other native browser extension.
 In AngularJS we do not allow intentional breaking changes to appear in versions where only the "patch"
 number changes. For example between 1.3.12 and 1.3.13 there can be no breaking changes. We do allow
 breaking changes happen between "minor" number changes. For example between 1.3.15 and 1.4.0 there
-will be a number of breaking changes. We also allow breaking changes between beta releases of AngularJS.
+are a number of breaking changes. That means AngularJS does not follow
+[semantic versioning (semver)](http://semver.org/) where breaking changes are only
+allowed when the "major" version changes.
+
+We also allow breaking changes between beta releases of AngularJS.
 For example between 1.4.0-beta.4 and 1.4.0-beta.5 there may be breaking changes. We try hard to minimize
 these kinds of change only to those where there is a strong use case such as a strongly requested feature
-improvement, a considerable simplification of the code or a measurable performance improvement.
+improvement, a considerable simplification of the code, a measurable performance improvement, or a better
+developer experience (especially with regard to updating to Angular).
+
+When we are making a release we generate updates to the changelog directly from the commits. This
+generated update contains a highlighted section that contains all the breaking changes that have been
+extracted from the commits. We can quickly see in the new changelog exactly what commits contain breaking
+changes and so can application developers when they are deciding whether to update to a new version of
+AngularJS.
+
+Features with non-breaking changes can also appear in the "patch" version, e.g. in version 1.6.3 there might
+be a feature that is not available in 1.6.2.
+
+Finally, deprecation of features might also appear in "minor" version updates. That means the features
+will still work in this version, but sometimes must be activated specifically.
+
+#### What is the version compatibility between AngularJS main and optional modules?
+
+AngularJS code is separated into a main module ("angular"), and a few different optional modules
+("angular-animate", "angular-route" etc) that are dependant on the main module.
+When a new AngularJS version is released, all modules are updated to the new version.
+This means that the main module and the optional modules must always have the exact same version,
+down the patch number, otherwise your application might break.
+
+Therefore you must always explicitly lock down your dependencies, for example in the package.json,
+the following ensures that "angular" and "angular-animate" are always updated to the same version.
+
+```
+{
+  "angular": "~1.6.0",
+  "angular-animate": "~1.6.0"
+}
+```
+
+#### How does AngularJS ensure code quality and guard against regressions?
 
 When adding new code to branches of AngularJS, have a very stringent commit policy:
 
@@ -37,8 +74,7 @@ tests must pass;
 - Commit messages must be written in a specific manner that allows us to parse them and extract the changes
 for release notes.
 
-The AngularJS code base has a very large set of unit tests (over 4000) and end to end tests, which are pretty
-comprehensive. This means that a breaking change will require one or more tests to be changed to allow the
+The AngularJS code base has a very large set of unit tests and end-to-end tests. This means that a breaking change will require one or more tests to be changed to allow the
 tests to pass. So when a commit includes tests that are being removed or modified, this is a flag that the
 code might include a breaking change. When reviewing the commit we can then decide whether there really is
 a breaking change and if it is appropriate for the branch to which it is being merged. If so, then we
@@ -49,12 +85,6 @@ over 2000 applications using the test suites of these applications. This allows
 quickly before a release. We've had a pretty good experience with this setup. Only bugs that affect features
 not used at Google or without sufficient test coverage, have a chance of making it through.
 
-Lastly, when we are making a release we generate updates to the changelog directly from the commits. This
-generated update contains a highlighted section that contains all the breaking changes that have been
-extracted from the commits. We can quickly see in the new changelog exactly what commits contain breaking
-changes and so can application developers when they are deciding whether to update to a new version of
-AngularJS.
-
 
 ### Is AngularJS a templating system?