[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.
@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.
See #2538 (comment)
TylerHelmuth
force-pushed
the
update-release-process
branch
from
7673370
to
268b45a
Compare
Description:
Update release process to warn against bumping Java and .NET versions.
Link to tracking Issue:
Related to #2542