Cross-link backwards compatibility policy with guidance
Add links to contributor and release manager guidance.
Closes
@@ -14,6 +14,7 @@ incompatible and require some changes from Bazel users.
* Expected breaking change in release X.Y: label **breaking-change-X.Y** (for example: [**breaking-change-0.21**](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Abreaking-change-0.21))
* Release X.Y is in a migration window: label **migration-X.Y** (for example: [**migration-0.21**](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Amigration-0.21))
+
## At a glance
1. Every breaking change is guarded with an `--incompatible_*` flag.
@@ -25,6 +26,12 @@ incompatible and require some changes from Bazel users.
1. APIs and behavior guarded by an `--experimental_*` flag can change at any time.
1. Users should never run their production builds with `--experimental_*` or `--incompatible_*` flags.
+### How to follow this policy
+
+* [For contributors - best practices for incompatible changes](../../breaking-changes-guide.html)
+* <a href='https://github.com/bazelbuild/continuous-integration/tree/master/docs/release-playbook.%6D%64'>For release managers - how to update issue labels and release</a>
+
+
## What is stable functionality?
In general, if an API or a behavior is available in Bazel without
@@ -86,3 +93,4 @@ are marked with a label "breaking-change-X.Y" (for example
[breaking-change-0.21](https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3Abreaking-change-0.21)).
+
