Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: outline go support policy #2839

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
44 changes: 0 additions & 44 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -714,50 +714,6 @@ spec:
exporters: [debug]
```

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should link to support.md here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

## Compatibility matrix

### OpenTelemetry Operator vs. OpenTelemetry Collector

The OpenTelemetry Operator follows the same versioning as the operand (OpenTelemetry Collector) up to the minor part of the version. For example, the OpenTelemetry Operator v0.18.1 tracks OpenTelemetry Collector 0.18.0. The patch part of the version indicates the patch level of the operator itself, not that of OpenTelemetry Collector. Whenever a new patch version is released for OpenTelemetry Collector, we'll release a new patch version of the operator.

By default, the OpenTelemetry Operator ensures consistent versioning between itself and the managed `OpenTelemetryCollector` resources. That is, if the OpenTelemetry Operator is based on version `0.40.0`, it will create resources with an underlying OpenTelemetry Collector at version `0.40.0`.

When a custom `Spec.Image` is used with an `OpenTelemetryCollector` resource, the OpenTelemetry Operator will not manage this versioning and upgrading. In this scenario, it is best practice that the OpenTelemetry Operator version should match the underlying core version. Given a `OpenTelemetryCollector` resource with a `Spec.Image` configured to a custom image based on underlying OpenTelemetry Collector at version `0.40.0`, it is recommended that the OpenTelemetry Operator is kept at version `0.40.0`.

### OpenTelemetry Operator vs. Kubernetes vs. Cert Manager

We strive to be compatible with the widest range of Kubernetes versions as possible, but some changes to Kubernetes itself require us to break compatibility with older Kubernetes versions, be it because of code incompatibilities, or in the name of maintainability. Every released operator will support a specific range of Kubernetes versions, to be determined at the latest during the release.

We use `cert-manager` for some features of this operator and the third column shows the versions of the `cert-manager` that are known to work with this operator's versions.

The OpenTelemetry Operator _might_ work on versions outside of the given range, but when opening new issues, please make sure to test your scenario on a supported version.

| OpenTelemetry Operator | Kubernetes | Cert-Manager |
|------------------------| -------------- | ------------ |
| v0.98.0 | v1.23 to v1.29 | v1 |
| v0.97.0 | v1.23 to v1.29 | v1 |
| v0.96.0 | v1.23 to v1.29 | v1 |
| v0.95.0 | v1.23 to v1.29 | v1 |
| v0.94.0 | v1.23 to v1.29 | v1 |
| v0.93.0 | v1.23 to v1.29 | v1 |
| v0.92.0 | v1.23 to v1.29 | v1 |
| v0.91.0 | v1.23 to v1.29 | v1 |
| v0.90.0 | v1.23 to v1.28 | v1 |
| v0.89.0 | v1.23 to v1.28 | v1 |
| v0.88.0 | v1.23 to v1.28 | v1 |
| v0.87.0 | v1.23 to v1.28 | v1 |
| v0.86.0 | v1.23 to v1.28 | v1 |
| v0.85.0 | v1.19 to v1.28 | v1 |
| v0.84.0 | v1.19 to v1.28 | v1 |
| v0.83.0 | v1.19 to v1.27 | v1 |
| v0.82.0 | v1.19 to v1.27 | v1 |
| v0.81.0 | v1.19 to v1.27 | v1 |
| v0.80.0 | v1.19 to v1.27 | v1 |
| v0.79.0 | v1.19 to v1.27 | v1 |
| v0.78.0 | v1.19 to v1.27 | v1 |
| v0.77.0 | v1.19 to v1.26 | v1 |
| v0.76.1 | v1.19 to v1.26 | v1 |

## Contributing and Developing

Please see [CONTRIBUTING.md](CONTRIBUTING.md).
Expand Down
59 changes: 59 additions & 0 deletions support.md
frzifus marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
# Support

## Go

When productised as a go libary or custom distribution the OpenTelemetry Operator project attempts to follow the supported go versions as [defined by the Go team](https://go.dev/doc/devel/release#policy).
frzifus marked this conversation as resolved.
Show resolved Hide resolved

Similar to the [opentelemetry collector](https://github.com/open-telemetry/opentelemetry-collector?tab=readme-ov-file#compatibility), removing support for an unsupported Go version is not considered a breaking change.

Support for Go versions on the OpenTelemetry Operator is updated as follows:

The first release after the release of a new Go minor version N will add build and tests steps for the new Go minor version.
The first release after the release of a new Go minor version N will remove support for Go version N-2.

Official OpenTelemetry Operator binaries may be built with any supported Go version.

# Compatibility matrix

### OpenTelemetry Operator vs. OpenTelemetry Collector

The OpenTelemetry Operator follows the same versioning as the operand (OpenTelemetry Collector) up to the minor part of the version. For example, the OpenTelemetry Operator v0.18.1 tracks OpenTelemetry Collector 0.18.0. The patch part of the version indicates the patch level of the operator itself, not that of OpenTelemetry Collector. Whenever a new patch version is released for OpenTelemetry Collector, we'll release a new patch version of the operator.

By default, the OpenTelemetry Operator ensures consistent versioning between itself and the managed `OpenTelemetryCollector` resources. That is, if the OpenTelemetry Operator is based on version `0.40.0`, it will create resources with an underlying OpenTelemetry Collector at version `0.40.0`.

When a custom `Spec.Image` is used with an `OpenTelemetryCollector` resource, the OpenTelemetry Operator will not manage this versioning and upgrading. In this scenario, it is best practice that the OpenTelemetry Operator version should match the underlying core version. Given a `OpenTelemetryCollector` resource with a `Spec.Image` configured to a custom image based on underlying OpenTelemetry Collector at version `0.40.0`, it is recommended that the OpenTelemetry Operator is kept at version `0.40.0`.

### OpenTelemetry Operator vs. Kubernetes vs. Cert Manager

We strive to be compatible with the widest range of Kubernetes versions as possible, but some changes to Kubernetes itself require us to break compatibility with older Kubernetes versions, be it because of code incompatibilities, or in the name of maintainability. Every released operator will support a specific range of Kubernetes versions, to be determined at the latest during the release.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i assume a follow up will be done to close #2798 ?


We use `cert-manager` for some features of this operator and the third column shows the versions of the `cert-manager` that are known to work with this operator's versions.

The OpenTelemetry Operator _might_ work on versions outside of the given range, but when opening new issues, please make sure to test your scenario on a supported version.

| OpenTelemetry Operator | Kubernetes | Cert-Manager |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we mention in the RELEASE.md that this file needs to be upgraded?

| ---------------------- | -------------- | ------------ |
| v0.98.0 | v1.23 to v1.29 | v1 |
| v0.97.0 | v1.23 to v1.29 | v1 |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs to be updated

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah the ordering here looks off too...

| v0.90.0 | v1.23 to v1.28 | v1 |
| v0.96.0 | v1.23 to v1.29 | v1 |
| v0.95.0 | v1.23 to v1.29 | v1 |
| v0.94.0 | v1.23 to v1.29 | v1 |
| v0.93.0 | v1.23 to v1.29 | v1 |
| v0.92.0 | v1.23 to v1.29 | v1 |
| v0.91.0 | v1.23 to v1.29 | v1 |
| v0.89.0 | v1.23 to v1.28 | v1 |
| v0.88.0 | v1.23 to v1.28 | v1 |
| v0.87.0 | v1.23 to v1.28 | v1 |
| v0.86.0 | v1.23 to v1.28 | v1 |
| v0.85.0 | v1.19 to v1.28 | v1 |
| v0.84.0 | v1.19 to v1.28 | v1 |
| v0.83.0 | v1.19 to v1.27 | v1 |
| v0.82.0 | v1.19 to v1.27 | v1 |
| v0.81.0 | v1.19 to v1.27 | v1 |
| v0.80.0 | v1.19 to v1.27 | v1 |
| v0.79.0 | v1.19 to v1.27 | v1 |
| v0.78.0 | v1.19 to v1.27 | v1 |
| v0.77.0 | v1.19 to v1.26 | v1 |
| v0.76.1 | v1.19 to v1.26 | v1 |