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.

Sign up for GitHub

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

[chore] Update release process #2543

Merged
merged 1 commit into from
Jan 23, 2024
Merged

[chore] Update release process #2543

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ Steps to release a new version of the OpenTelemetry Operator:

1. Change the `versions.txt`, so that it lists the target version of the OpenTelemetry Collector (operand), and the desired version for the target allocator and the operator. The `major.minor` should typically match, with the patch portion being possibly different.
2. Change the `autoinstrumentation-*` versions in `versions.txt` as per the latest supported versions in `autoinstrumentation/`.
- :warning: DO NOT BUMP JAVA PAST `1.32.X` AND DO NOT BUMP .NET PAST `1.2.0`. :warning: Upgrades past these versions will introduce breaking HTTP semantic convention changes.
Copy link
Member

Choose a reason for hiding this comment

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

+1

Copy link
Contributor

Choose a reason for hiding this comment

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

@TylerHelmuth, http/network semantic convention was changed for ASP.NET, ASP.NET Core and HTTP Instrumentation. There is no support for old sem. conv.

Theoretically (I know that the real world is different), it is not a problem:

  1. Previously http and network sem. conv. was not stable. There were no breaking changes after stabilization.
  2. There were no stable instrumentation libraries in OTel for .NET. The version with new sem. conv. is first stable release.
  3. All instrumentations are/were marked as not stable in automatic instrumentation. As long as they are not stable, we can release minor versions.
  4. Operator is not stable (<1.0.0).

What is more, OTel Sem. conv. will accept a lot of breaking changes in the future for non-stable parts. If e.g. SQL/DB sem/ conv. will be marked as stable, do you recommend to release Java 3.0? If not, why? It is serious question, I do not have a good answer. Do you have a plan to block such upgrades here?

What's about dropping support for .NET6 and .NET7. Both of them will reach EOL this year. .NET team decided to support only currently supported versions (without rising major version). Do you have plan to also block the upgrade versions here?

IMO all these cases touches same issue problem and I do not have good answer. Still, theoretically we do not do anything against policies and we can make upgrades with clear statement in changelog.

Originally posted by @Kielek in #2538 (comment)

Copy link
Member Author

Choose a reason for hiding this comment

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

See #2538 (comment)

3. Run `make bundle DOCKER_USER=open-telemetry VERSION=0.38.0`, using the version that will be released.
4. Change the compatibility matrix in the [readme](./README.md) file, using the OpenTelemetry Operator version to be released and the current latest Kubernetes version as the latest supported version. Remove the oldest entry.
5. Add the changes to the changelog. Manually add versions of all operator components.
Expand Down
Loading