Problem
setup phase silently bumps the consumer's go directive and OTel dependency versions.
Nothing in the setup output tells the user this happened, and since go.mod is restored by cleanup after a successful build, the user may never notice. We should advise users which versions are going to be used during the build.
The root cause is that every hook module in pkg/instrumentation/**/go.mod pins go 1.25.0 and otel v1.43.0, the maintainer's current dev version, not the minimum required. When syncDeps adds replace directives and runs go mod tidy, Go's MVS raises the consumer to match.
Proposed fix
A. Lower the declared floor in hook modules to the minimum go version and OTel version the hook code actually requires (likely go 1.23 / otel v1.38). Add a CI matrix to prevent the floor from silently drifting back up.
B. In syncDeps, before running go mod tidy, compare the consumer's go.mod against each matched hook and emit a visible warning listing any version that would be raised (old → new, which hook forced it).
Problem
setupphase silently bumps the consumer'sgodirective and OTel dependency versions.Nothing in the setup output tells the user this happened, and since
go.modis restored by cleanup after a successful build, the user may never notice. We should advise users which versions are going to be used during the build.The root cause is that every hook module in
pkg/instrumentation/**/go.modpinsgo 1.25.0andotel v1.43.0, the maintainer's current dev version, not the minimum required. WhensyncDepsaddsreplacedirectives and runsgo mod tidy, Go's MVS raises the consumer to match.Proposed fix
A. Lower the declared floor in hook modules to the minimum
goversion and OTel version the hook code actually requires (likelygo 1.23/otel v1.38). Add a CI matrix to prevent the floor from silently drifting back up.B. In
syncDeps, before runninggo mod tidy, compare the consumer'sgo.modagainst each matched hook and emit a visible warning listing any version that would be raised (old → new, which hook forced it).