-
Notifications
You must be signed in to change notification settings - Fork 414
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
[chore] Update release process #2543
[chore] Update release process #2543
Conversation
@@ -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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
There was a problem hiding this comment.
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:
- Previously http and network sem. conv. was not stable. There were no breaking changes after stabilization.
- There were no stable instrumentation libraries in OTel for .NET. The version with new sem. conv. is first stable release.
- All instrumentations are/were marked as not stable in automatic instrumentation. As long as they are not stable, we can release minor versions.
- 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)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #2538 (comment)
7673370
to
268b45a
Compare
Description:
Update release process to warn against bumping Java and .NET versions.
Link to tracking Issue:
Related to #2542