docs(FAQ): add info about Anglar 1's versioning strategy

See #10122 (comment)

Author: petebacondarwin

docs/content/misc/faq.ngdoc

@@ -20,6 +20,42 @@ AngularJS is 100% JavaScript, 100% client-side and compatible with both desktop
 So it's definitely not a plugin or some other native browser extension.
 
 
+### What is the AngularJS versioning strategy?
+
+In Angular 1 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 Angular.
+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.
+
+When adding new code to branches of Angular, have a very stringent commit policy:
+
+- Every commit must contain tests and documentation updates alongside the code changes and that all the
+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 Angular 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
+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
+require that the commit message contains an appropriate breaking change message.
+
+Additionally, when a commit lands in our master repository it is synced to Google where we test it against
+over 2000 applications using the test suites of these applications. This allows us to catch regressions
+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 fro 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
+Angular.
+
+
 ### Is AngularJS a templating system?
 
 At the highest level, Angular does look like just another templating system. But there is one