Move to go modules #43
Conversation
ferhatelmas
commented
Nov 6, 2019
ferhatelmas
commented
- update travis to latest 2 versions
- put a empty line to internal import and 3rd part dependency
* update travis to latest 2 versions * put a empty line to internal import and 3rd part dependency
| @@ -0,0 +1,10 @@ | |||
| module github.com/GetStream/stream-go2/v4 | |||
There was a problem hiding this comment.
why would we include /v4 to the module name? sounds redundant
There was a problem hiding this comment.
There are already 3.x releases and it's a best practice to bump major while introducing modules.
There was a problem hiding this comment.
yes but why are we adding the version to the name of the module? can't we just create a v4.0.0 tag?
There was a problem hiding this comment.
module github.com/GetStream/stream-go2
There was a problem hiding this comment.
I am sure we can find a solution that does not require having version name as part of module and package names; that's ugly
There was a problem hiding this comment.
It's the convention of go tool works with major versions.
I think it's not ugly, but explicit.
If you really want to go tag way only, I can update similar to stripe-go but beware not standard in terms of introducing breaking changes.
There was a problem hiding this comment.
I came across with wrong module support addition without version suffix in the module name.
should be github.com/mholt/archiver/v4 but it's not so it's breaking and module supported go can only install v3.1.1 - last version before go.mod file was added.
There was a problem hiding this comment.
Just passing by (got here via the linked module issue in mholt/archiver), but wanted to note that @ferhatelmas is correct -- Go modules with a major version beyond v1 are required to have the major version as a suffix of their module name per the module specification. See https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher, which discusses this exact scenario (transitioning a repository that is already at v2+ to modules). https://blog.golang.org/v2-go-modules discusses this as well. As noted here, not including the major version as part of the module while having tags that are beyond v0/v1 will result in suboptimal behavior when trying to consume the module (as is currently the case with archiver). Unfortunately this issue/confusion appears to be quite common: golang/go#31543
There was a problem hiding this comment.
@nmiyake thanks for chiming in to give further clarification and links.
Also thanks for the archiver fix 😉
|
@tbarbugli I'm going forward with this change for better consistency between repositories. |
