OpenTelemetry SDK Versions

Workflow

the SDKs table has one primary SDK package per language; the Components table covers the Collector (core, contrib, distributions, builder), the configuration schema, semantic conventions, and Weaver
use the bundled tables as the default source of truth for what they cover
its "Versions last changed" date is the last day any row changed
offline, give each version with that date: "<version> as of <date>; a newer release may exist". Never call it the current latest

prefer the latest released version when it is compatible with the project
if the latest release is not compatible, choose the latest compatible version and state the compatibility reason explicitly
reuse that decision for the rest of the task unless the language, package, or constraints change

if the task requires additional packages from the same ecosystem (exporters, instrumentations, resource detectors, Collector components), look up their versions from the release source — do not infer or reuse the primary package version
sub-packages within the same project often share a version line but not always; confirm each package individually
Collector components in one build must match the core release line its builder uses, which can trail core; see otel-collector-builder for manifest pinning