Upgrade dependencies

[vnxme]

This PR bumps Go to 1.22, removes Go 1.21 checks, adds Go 1.23 checks and upgrades dependencies.

I have a deprecation warning about github.com/golang/protobuf v1.5.4 // indirect. My IDE suggests that google.golang.org/protobuf should be used instead. But I'm not sure whether we could fix it since it is an indirect requirement.

[mohammed90]

I have a deprecation warning about github.com/golang/protobuf v1.5.4 // indirect

Can you run go mod why github.com/golang/protobuf to know where it's coming from and resolve in via the direct dependency?

[vnxme]

@mohammed90 That's what I have:

go mod why -m github.com/golang/protobuf
# github.com/golang/protobuf
github.com/caddyserver/caddy/v2/modules/standard
github.com/caddyserver/caddy/v2/modules/caddypki/acmeserver
github.com/smallstep/nosql
github.com/smallstep/nosql/badger/v1
github.com/dgraph-io/badger
github.com/golang/protobuf/proto

I've found a related issue created 4 months ago. This PR tries to resolve it but either there are some problems with it or there is no feedback from the developers, I don't know.

We use github.com/smallstep/nosql requiring github.com/dgraph-io/badger in this place of the mainline code only.

[francislavoie]

We'll just have to ignore that deprecation for now.

[mohammed90]

One last question: did you upgrade the transitive dependencies directly or via upgrading the direct deps?

[vnxme]

What I did is actually go get -u ./... and go mod tidy. I didn't modify any direct/indirect deps versions manually except for github.com/dgraph-io/ristretto (with v1.0.0 it wouldn't build).

[mohammed90]

Then please revert the changes and only touch direct dependencies. Messing with the others could cause unforeseen trouble. Let the transitive deps be managed my the upstream.

[francislavoie]

To clarify, this is due to how xcaddy works, using Go build tooling. If you use versions higher then Caddy in a plugin, then it forces Caddy to use those higher versions even if they might not actually be compatible (API breaks) so it could fail compilation. Only update the direct deps of the plugin to avoid trouble, and don't use higher versions than actually necessary (don't bump versions just for the sake of bumping).

[vnxme]

@mohammed90 @francislavoie Thank you for explanations. I reverted the changes and did go get -u instead of go get -u ./..., all remaining commands/actions were the same as before. Now it won't build in my IDE due to multiple errors in go.opentelemetry.io/otel/sdk/trace.

go mod why -m go.opentelemetry.io/otel/sdk/trace output:

# go.opentelemetry.io/otel/trace
github.com/caddyserver/caddy/v2/modules/standard
github.com/caddyserver/caddy/v2/modules/caddyhttp/standard
github.com/caddyserver/caddy/v2/modules/caddyhttp/tracing
go.opentelemetry.io/otel/trace

Build errors:

# go.opentelemetry.io/otel/sdk/trace
..\..\..\..\go\pkg\mod\go.opentelemetry.io\otel\[email protected]\trace\span.go:165:20: cannot use (*recordingSpan)(nil) (value of type *recordingSpan) as ReadWriteSpan value in variable declaration: *recordingSpan does not implement ReadWriteSpan (missing method AddLink)
		have addLink("go.opentelemetry.io/otel/trace".Link)
		want AddLink("go.opentelemetry.io/otel/trace".Link)
..\..\..\..\go\pkg\mod\go.opentelemetry.io\otel\[email protected]\trace\span.go:787:20: cannot use nonRecordingSpan{} (value of type nonRecordingSpan) as "go.opentelemetry.io/otel/trace".Span value in variable declaration: nonRecordingSpan does not implement "go.opentelemetry.io/otel/trace".Span (missing method AddLink)
..\..\..\..\go\pkg\mod\go.opentelemetry.io\otel\[email protected]\trace\tracer.go:50:21: impossible type assertion: p.(*recordingSpan)
	*recordingSpan does not implement "go.opentelemetry.io/otel/trace".Span (missing method AddLink)
		have addLink("go.opentelemetry.io/otel/trace".Link)
		want AddLink("go.opentelemetry.io/otel/trace".Link)
..\..\..\..\go\pkg\mod\go.opentelemetry.io\otel\[email protected]\trace\tracer.go:120:10: cannot use tr.newNonRecordingSpan(sc) (value of type nonRecordingSpan) as "go.opentelemetry.io/otel/trace".Span value in return statement: nonRecordingSpan does not implement "go.opentelemetry.io/otel/trace".Span (missing method AddLink)
..\..\..\..\go\pkg\mod\go.opentelemetry.io\otel\[email protected]\trace\tracer.go:122:9: cannot use tr.newRecordingSpan(psc, sc, name, samplingResult, config) (value of type *recordingSpan) as "go.opentelemetry.io/otel/trace".Span value in return statement: *recordingSpan does not implement "go.opentelemetry.io/otel/trace".Span (missing method AddLink)
		have addLink("go.opentelemetry.io/otel/trace".Link)
		want AddLink("go.opentelemetry.io/otel/trace".Link)

I don't know why go get -u upgrades go.opentelemetry.io/otel to 1.29.0 while Caddy (both 2.8.4 and master) explicitly requires 1.24.0. Shall I avoid using go get -u at all?

[vnxme]

Shall I avoid using go get -u at all?

I reverted again, edited direct dependencies manually leaving indirect ones for go mod tidy to deal with. Now it builds OK again.

[mohammed90]

Shall I avoid using go get -u at all?

I'm not 100% sure of how it behaves when run without any arguments. It's best to be explicit.

[mohammed90]

Thanks for working on it!