Define and document the OBI v1 support matrix

[MrAlias]

As part of the OBI v1.0 release contract, we need to explicitly define and document which environments are supported.

Today, support expectations are spread across code, docs, tests, and tribal knowledge. That is not sufficient for v1.

Goal

Produce a documented v1 support matrix that clearly states what OBI supports, what is best-effort, and what is out of scope.

Scope

The v1 support matrix should cover at least:

• Linux kernel support expectations
• supported CPU architectures
• supported release artifacts and image platforms
• supported deployment environments where relevant
• supported language runtimes and library-version ranges where OBI makes compatibility claims
• explicitly unsupported or development-only environments

Tasks

• Define the kernel versions and kernel families that are part of the v1 support contract
• Define supported CPU architectures for v1
• Define supported release artifacts and container image platforms
• Define supported runtime/library compatibility claims that are part of the v1 contract
• Define which environments are explicitly outside the v1 compatibility contract
• Document the support matrix in the appropriate user-facing location(s)
• Link the published support matrix from the v1.0 release epic

Acceptance Criteria

• A clear v1 support matrix exists in user-facing documentation
• The matrix distinguishes supported, unsupported, and out-of-contract environments
• Maintainers agree this matrix is the compatibility baseline for v1.0

[MrAlias]

One thing this issue should explicitly reconcile before v1: the current support statements in this repository do not fully line up with what opentelemetry.io says today.

For example, the OBI landing page currently lists a distro compatibility set including Ubuntu 20.04/21.04/22.04/23.04, CentOS 7/8/9, AlmaLinux 8/9, Rocky Linux 8/9, RHEL 8/9, Debian 11/12, openSUSE Leap 15.3/15.4, and SLES 15 SP4.

The repository itself is much more defensible today on:

• Linux amd64 / arm64 release artifacts
• kernel-based requirements (5.8+, with the documented RHEL-family 4.18+ exception)
• BTF requirement
• specific CI validation coverage
• selected runtime and library baselines

That means this should not just document a support matrix in the abstract. It should also decide whether the broader opentelemetry.io distro/version claims remain part of the intended v1 contract, and either:

• justify them with repo-backed validation and maintainer intent, or
• narrow the public docs so users are not given a broader support contract than the project actually wants to own.

I would treat that repo/docs reconciliation as part of the deliverable for this issue.