Proper go.mod support

[harshavardhana]

Such that moving the API to github.com/golang-jwt/jwt/v3 for v3 releases. This helps downstream projects such as github.com/minio/minio - to pin to a correct release.

The problem with go.mod's - v3.2.1+incompatible would simply be unexpected

The original issue that was neverhttps://github.com/dgrijalva/jwt-go/issues/294

[oxisto]

HI @harshavardhana, thanks for the interest in this project. I am not quite sure if I understand your issue correctly. The + incompatible is just an indication of Go's forced SIV-style being "ignored", because the original author did so. It should not hinder you in any way to "pin" to a certain release, such as the current v3.2.1+incompatible.

We had a rather long going-forth-and-back-discussion on this topic, mainly in #17 and #5 (including also the attempt to re-release starting from v1, but this did not work because of already cached old versions in the proxy) and decided that we do want to support go modules properly at some point, but not during the v3 releases. This is mainly due to the fact that we wanted to have a 1:1 drop-in replacement first, fixing major things and then move to a v4 release. We decided against switching to a SIV-style import path during the v3 releases and moved this to v4.

We have yet to fix a proper release schedule, I have started something here: https://github.com/golang-jwt/jwt/milestones, but it is far from complete. Most of the people involved here were a little busy with end of quarter / holiday stuff. So stay tuned.

[harshavardhana]

HI @harshavardhana, thanks for the interest in this project. I am not quite sure if I understand your issue correctly. The + incompatible is just an indication of Go's forced SIV-style being "ignored", because the original author did so. It should not hinder you in any way to "pin" to a certain release, such as the current v3.2.1+incompatible.

We had a rather long going-forth-and-back-discussion on this topic, mainly in #17 and #5 and decided that we do want to support go modules properly at some point, but not during the v3 releases. This is mainly due to the fact that we wanted to have a 1:1 drop-in replacement first, fixing major things and then move to a v4 release. We decided against switching to a SIV-style import path during the v3 releases and moved this to v4.

We have yet to fix a proper release schedule, I have started something here: https://github.com/golang-jwt/jwt/milestones, but

Yes I saw that after opening the issue, looks like there is no easy way out. Looking forward to v4 implementation.

[oxisto]

I will keep this open as a reminder, until we address it in v4.

[mfridman]

One could make the case this package doesn't really need module support. And the only real side-effect afaics is the "ugly" +incompatible suffix

1. there are no external dependencies
2. consumers of this package do not need a modules file to use it

Just curious, are there any tooling problems or issues users may be experiencing due to a lack of module support?

FYI I'm not against adding go.mod file, would like to understand if there is a more pressing need to get to a /v4 ?

[oxisto]

I think the main concern is that at "some" point, Go will drop support for building in $GOPATH, effectively forcing the use of Go modules. It was originally announced, that $GOPATH will be deprecated in Go 1.17 according to https://blog.golang.org/go116-module-changes.

We plan to drop support for GOPATH mode in Go 1.17. In other words, Go 1.17 will ignore GO111MODULE. If you have projects that do not build in module-aware mode, now is the time to migrate. If there is a problem preventing you from migrating, please consider filing an issue or an experience report.

However, I cannot find any reference to that in the Go 1.17 beta, so I guess this is postponed for now.

[mfridman]

I propose we bite the bullet and adopt modules.

Introducing this package as a /v4 module will maintain backwards compatible with the current v3.2.1+incompatible and the upstream github.com/dgrijalva/jwt-go v3.2.0+incompatible ?

Consumers, if they want proper module support, will still have to update their import paths .. but this is typically and there is tooling to help.

In the future, if we wanted to introduce breaking changes those would be added as /v5, correct ?