Bump opentelemetry-java from 1.32.0 to 2.4.0

[paketo-bot]

Bumps opentelemetry-java from 1.32.0 to 2.4.0.

[dmikusa]

There are a number of breaking changes. Let's hold off on this for now. We can either add this later or we can add a second branch.

https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/tag/v2.0.0

[ThomasVitale]

There are a number of breaking changes. Let's hold off on this for now. We can either add this later or we can add a second branch.

https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/tag/v2.0.0

Thanks for catching this! It's good to pause this for now and work separately on a new major release of this buildpack to support the new SDK.

[dmikusa]

@ThomasVitale We will often carry two major versions to give users time to switch over. At the moment, this buildpack only has one. Whether it's valuable to do that or not often depends on the upstream project. Do you think that would offer value here? or are users likely to quickly upgrade to 2.0 and thus it's not as important?

There is some overhead in carrying two major versions so we only typically do that when there's value. What do you think?

[ThomasVitale]

@ThomasVitale We will often carry two major versions to give users time to switch over. At the moment, this buildpack only has one. Whether it's valuable to do that or not often depends on the upstream project. Do you think that would offer value here? or are users likely to quickly upgrade to 2.0 and thus it's not as important?

There is some overhead in carrying two major versions so we only typically do that when there's value. What do you think?

@dmikusa That's a good point. I suggested the major version bump to signal to users that there are major changes in the Buildpack (mostly around OTel configuration and naming of traces), so that they are more conscious of the consequences before upgrading.

But I wasn't considering keeping the current major line active. Could that be an option? Prepare a version 2 of the Buildpack and, once released, stop any update on the version 1 train?

Since this Buildpack is not included in any published Paketo builder or package, and it must be used explicitly as an add-on, there might not be enough value in having a transition period where both major release trains are actively maintained.

What do you think?

[ThomasVitale]

Additional information: the OTel Java Instrumentation 1.32.x line will only be supported (only security patches) by the OTel project until May.

[dmikusa]

OK, adding support for both branches is typically something we'd do when both branches of the upstream dependency are going to be around for a long time. Tomcat is a good example of that. Since OTel 1.x is only supported till May, what I would propose is that we hold off on the upgrade until closer to that date. Then we can cut a final release of the buildpack with the 1.x branch. At that point, we'll bump the dependency to 2.0 and cut a 2.0.0 release of the buildpack.

People can hang back on the final 1.x version of the buildpack as they migrate, but they will ultimately need to go to 2.0. Once we go to 2.0.0 with the buildpack, we don't go back and update older buildpack branches. There are too many permutations of buildpacks and dependencies, and we just don't have the resources to do that.

[ThomasVitale]

@dmikusa I like the plan, let's go with that. Should we close this PR and track the future 2.x support in #113 (since there will be some changes to the buildpack implementation besides the version bump)?

[ThomasVitale]

@dmikusa we can probably close this in favour of #132