Simplify CONTRIBUTING versioning documentation (google#1266)

Let's let semver.org do most of the heavy lifting
Follow on to google#1155

CONTRIBUTING.md

@@ -52,30 +52,11 @@ about changes in model-viewer causing regressions in their use of the
 component. However, it’s also important that we continue to improve
 model-viewer, making changes to improve ergonomics and rendering quality.
 
-In general, <model-viewer> follows semver. Major versions (`X.y.z`) are used for
-the largest features and backwards-incompatible changes (more below on that),
-minor versions (`x.Y.z`) are used for new features, and patch versions (`x.y.Z`)
-are used for bug fixes.
-
-When possible please keep your changes backwards-compatible - including
-keeping both existing APIs and rendering consistent. When that’s not possible,
-we’ll follow a three-step process across several [semver](semver.org) major
-versions (in the `0.y.z` versions leading up to 1.0, we’ll use the minor
-version - `y` - for the same purpose): 
-
-1) Add a new optional API to enable the new behavior; in the release notes,
-document the new behavior, as well that it will become the default in the
-next version (in for instance the `2.0.0` release)
-1) Make the new API default enabled (allow it to be explicitly disabled for
-the old behavior); in the release notes, document this change, and that the
-API will be removed in the next version (the `3.0.0` release)
-1) Remove the API (the `4.0.0` release)
-
-Breaking changes mostly center around anything that the developer would have
-to take action on. This includes changes in APIs, or changes to the model
-staging/lighting that they might want to undo in order to achieve the effect
-that they currently enjoy.
-
-Additive changes (a new API) aren’t breaking, nor are smaller changes (a fix
-to the correctness of reflections, or a 1% change in padding).
-
+To this end <model-viewer> will adhere to [semver](https://semver.org). We
+consider the API as documented on [modelviewer.dev](https://modelviewer.dev)
+our public API.
+
+We'll also strive to keep rendering changes in the spirit of semver - although
+most of our rendering changes are likely to be increased adherence to PBR,
+which we wouldn't consider to be an incompatible change for purposes of
+semver.