docs: document API stability

Write down the guidelines we've been using to decide whether a breaking
change is acceptable or not.

Signed-off-by: Lorenz Bauer <lmb@isovalent.com>

CONTRIBUTING.md

@@ -12,6 +12,17 @@ a better understanding for the high-level goals.
 2. (*optional*) Create a draft PR if you want to discuss the implementation or have hit a problem. It's fine if this doesn't compile or contains debug statements.
 3. Create a PR that is ready to merge. This must pass CI and have tests.
 
+### API stability
+
+The library doesn't guarantee the stability of its API at the moment.
+
+1. If possible avoid breakage by introducing new API and deprecating the old one
+   at the same time. If an API was deprecated in v0.x it can be removed in v0.x+1.
+2. Breaking API in a way that causes compilation failures is acceptable but must
+   have good reasons.
+3. Changing the semantics of the API without causing compilation failures is
+   heavily discouraged.
+
 ## Running the tests
 
 Many of the tests require privileges to set resource limits and load eBPF code.