From 26f0fcfe90703db73244ebf327c2ebc7258980fe Mon Sep 17 00:00:00 2001 From: Pablo Baeyens Date: Mon, 16 Dec 2024 17:06:01 +0100 Subject: [PATCH] [chore] [docs/component-stability.md] Document relationship between versioning and stability (#11863) #### Description Documents relationship between component stability and versioning. #### Link to tracking issue Fixes #11851 --- docs/component-stability.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/docs/component-stability.md b/docs/component-stability.md index b8a477f19b4..831945a453a 100644 --- a/docs/component-stability.md +++ b/docs/component-stability.md @@ -187,3 +187,12 @@ Components that were accepted based on being vendor-specific components will be they have no active code owners from the vendor even if there are other code owners listed. As part of being marked unmaintained, we'll attempt to contact the vendor to notify them of the change. Other active code owners may petition for its continued maintenance if they want, at which point the component will no longer be considered vendor-specific. + +## Versioning + +Components are Go modules and as such follow [semantic versioning](https://semver.org/). Go API stability guarantees are covered in the [VERSIONING.md](../VERSIONING.md) document. +The versioning of the components applies to all signals simultaneously. For a component to be marked as 1.x it MUST be stable for at least one signal. + +Even if a component has a 1.x or greater version, its behavior for specific signals might change in ways that break end users if the component is not stable for a particular signal. +Go API stability guarantees apply to ALL signals, regardless of their stability level. +This means that signal-specific configuration options MUST NOT be removed or changed in a way that breaks our Go API compatibility promise, even if the signal is not stable.