v4.0.0-rc1 tag is missing

[mx-psi]

The v4.0.0-rc1 tag is available on the pkg.go.dev docs domain and the official Go proxy (download here, sumdb entry here), but it looks like the tag has been removed from this repository.

This breaks build for anyone that is not using the official Go proxy and is building a module that has v4.0.0-rc1 on their dependency tree. Would it be possible for this tag to be re-added to the repository to avoid this breakage? Thanks!

[VojtechVitek]

This was a release candidate, not a stable release. It's likely we removed the tag for reason and not by mistake.

Please refer to v4.0.0 instead.

[mx-psi]

This was a release candidate, not a stable release. It's likely we removed the tag for reason and not by mistake.

The problem is the version still exists on the official Go proxy so most Go users will not notice that and keep on using this version.

Please refer to v4.0.0 instead.

The only version that exists for Go is v4.0.0-rc1:

❯ go list -m -versions github.com/go-chi/chi/v4
github.com/go-chi/chi/v4 v4.0.0-rc1

v4.0.0 only exists as an incompatible version of github.com/go-chi/chi, so it is not an option if the module people are using is github.com/go-chi/chi/v4, which is the proper thing to do according to the Go modules reference.

[pkieltyka]

yes, official go.mod support was released from /v5

/v4 was never a thing. Is there a particular reason to add v4.0.0-rc1 now..? I feel it will be mistaken for users to use /v4. I'd need to look closer at this, and unfortunately I don't have the bandwidth right now -- just checking if this is urgent and why?

[Aneurysm9]

just checking if this is urgent and why?

We have multiple developers running into problems caused by this missing tag and the inability to use the Go proxy. As @mx-psi mentioned:

This breaks build for anyone that is not using the official Go proxy and is building a module that has v4.0.0-rc1 on their dependency tree.

I'd love it if our intermediate dependency didn't have that transitive dependency, but that's not in my control. I also can't exclude this version and hope to get a correct version since v5 is a distinct module.

[pkieltyka]

I’m not even sure how to properly solve this? I can tag 4.0.0-rc1 but maybe I should release a 4.x.x release off the last v4 incompatible release with go.mod support for /v4. The go.mod stuff is such a mess the behaviour is difficult to predict

[pkieltyka]

Btw, for dd-trace and open-telemetry, please upgrade to chi /v5. There should be no reason a project is using /v4 or an old version, if they are, or any child dependency is using it, they should upgrade as its backwards compatible.

[mx-psi]

I’m not even sure how to properly solve this? I can tag 4.0.0-rc1 but maybe I should release a 4.x.x release off the last v4 incompatible release with go.mod support for /v4. The go.mod stuff is such a mess the behaviour is difficult to predict

Tagging v4.0.0-rc1 again on the same commit as it was before would solve the problem. Tagging a new version on v4 would provide a workaround, but it means that every package with v4.0.0-rc1 on its dependency tree would need to bump the version on their go.mod.

Btw, for dd-trace and open-telemetry, please upgrade to chi /v5. There should be no reason a project is using /v4 or an old version, if they are, or any child dependency is using it, they should upgrade as its backwards compatible.

On dd-trace the usage is to provide a middleware (see https://github.com/DataDog/dd-trace-go/blob/v1/contrib/go-chi/chi.v4/chi.go ) for other users to use, so I don't think if this can be removed safely (maybe if you deprecate /v4 I can convince people to drop it, but it would still be a breaking change :( ).

The OpenTelemetry Collector does not directly make use of go-chi, but it uses it indirectly because it depends on dd-trace-go.