v0.3.0 tag causes problems with go module updates

[jvilhuber]

It seems there's a v0.3.0 tag on this repo, but the code seems to not be ready. When I update modules (perhaps a little too heavy-handed) with go get -u ./... it always tries to pull in this newer version:

go: upgraded github.com/quic-go/qtls-go1-20 v0.2.2 => v0.3.0

but it fails to compile:

../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:18:15: undefined: qtls.Alert
../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:24:26: undefined: qtls.CipherSuiteTLS13
../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:36:25: undefined: qtls.ConnectionStateWith0RTT
../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:38:25: undefined: qtls.EncryptionLevel
../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:40:19: undefined: qtls.Extension
../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:44:21: undefined: qtls.RecordLayer
../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:49:29: undefined: qtls.EncryptionHandshake
../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:51:24: undefined: qtls.Encryption0RTT
../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:53:31: undefined: qtls.EncryptionApplication
../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:58:14: undefined: qtls.AEADAESGCMTLS13
../../../../go/pkg/mod/github.com/quic-go/quic-go@v0.36.1/internal/qtls/go120.go:58:14: too many errors
make: *** [lint] Error 1

Am I doing something wrong? Or could this tag be removed until it is ready, so to not confused go module updates?

[marten-seemann]

The code here is ready, and it's already used by quic-go master. It's correctly tagged according to semver (it has breaking changes, so it's a minor version bump).

The problem is the Go tooling. go get -u, for some reason that I don't understand, assumes that it's valid to just randomly update (transitive) dependencies, even across breaking updates.

[marten-seemann]

It's also not possible to remove tags, again, thanks to the Go tooling (it's cached by the Go proxy).

[jvilhuber]

and it's already used by quic-go master

It's not yet released, right? I'll just live with it, until a new version of quic-go is released, then.

[iaburton]

Just wanted to chime in that I ran into the same thing doing a go get -u gihub.com/quic-go/quic-go to update from v0.35.1 to v0.36.2. I was actually unaware it updated transitive dependencies when the direct dependency itself doesn't specify it in its go.mod (meaning, quic-go v0.36.2 still wants v0.2.2 of this module, and yet go get -u updated it to v0.3 anyways even though that is the master dep). I did know it would update transitive deps if the dep itself required it.

I suppose the better way to update is to replace the version in the main go.mod then run go mod tidy rather than go get -u

Also fyi @marten-seemann there is a 'retract' directive that can be used (and something I personally forget about now and then), not sure if it would help in this situation though.
https://go.dev/ref/mod#go-mod-file-retract

In the meantime if anyone else runs into this, in your main module just modify the line
github.com/quic-go/qtls-go1-20 v0.3.0 // indirect
to
github.com/quic-go/qtls-go1-20 v0.2.2 // indirect
And rerun go mod tidy. It should build again.

[marten-seemann]

I really don't know how to solve this. This is a problem with the Go tooling, not with any of the repos here.

qtls v0.3.0 will be used by quic-go v0.37.0 (and it already is used by master). v0.3.0 is totally fine, which is why I cut the release. It contains breaking changes, so it's a minor version bump, as per semver rules. I needed the release to merge the corresponding commit into quic-go master (otherwise I would've had to import an untagged commit). It would feel like an abuse of retractions to retract a perfectly fine release.

Also keep in mind that in general, a (transitive) dependency might be provided by a third party. It needs to be possible for that dependency to release a new version with breaking changes, without the Go toolchain breaking everyone.

[iaburton]

I agree this likely isn't something that needs "solving" :) was just pointing out it happened to more than one individual and (then provided) a simple enough solution for those that happen to find this issue. Really the only confusing part was finding which transitive dependency was the "issue". Maybe a temporary link in the readme of https://github.com/quic-go/quic-go pointing to this issue would suffice, at least until v0.37 (again, I know neither module is the problem, v0.37 will simply "solve" it as v0.3 of this module is required at that point and if someone makes the mistake we did, it will still build).

[marten-seemann]

quic-go v0.37.0 was just released. I hope that makes this problem occur less often...

[jvilhuber]

Letting my go projects update to v0.37.0 (actually v0.37.1, since I was asleep at the wheel for a few weeks!) works for me. Closing this issue!