search

jordan-wright / email

Robust and flexible email library for Go
MIT License
2.65k stars 321 forks source link

Cannot get latest version: module contains a go.mod file, so module path should be github.com/jordan-wright/email/v4 #121

Closed KateGo520 closed 4 years ago

KateGo520 commented 4 years ago

Background

The github.com/jordan-wright/email uses Go modules and the current release version is v4. And it’s module path is "github.com/jordan-wright/email", instead of "github.com/jordan-wright/email/v4". It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:

A package that has opted in to modules must include the major version in the import path to import any v2+ modules To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2. https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Steps to Reproduce

GO111MODULE=on, run go get targeting any version >= v4.0.0 of the jordan-wright/email:

$ go get github.com/jordan-wright/email@v4.0.0
go: finding github.com/jordan-wright/email v4.0.0
go: finding github.com/jordan-wright/email v4.0.0
go get github.com/jordan-wright/email@v4.0.0: github.com/jordan-wright/email@v4.0.0: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v4

SO anyone using Go modules will not be able to easily use any newer version of jordan-wright/email.

Solution

1. Kill the go.mod files, rolling back to GOPATH.

This would push them back to not being managed by Go modules (instead of incorrectly using Go modules). Ensure compatibility for downstream module-aware projects and module-unaware projects projects

2. Fix module path to strictly follow SIV rules.

Patch the go.mod file to declare the module path as github.com/jordan-wright/email/v4 as per the specs. And adjust all internal imports. The downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide,govendor…).

*[]** You can see who will be affected here: [53 module-unaware user, i.e., maximus-next/repo.nefrosovet.ru, signal18/replication-manager, lockys/Awesome.json] https://github.com/search?q=github.com%2Fjordan-wright%2Femail+extension%3Ajson+extension%3Aconf+extension%3Atoml+extension%3Alock&type=Code

If you don't want to break the above repos. This method can provides better backwards-compatibility. Release a v2 or higher module through the major subdirectory strategy: Create a new v4 subdirectory (github.com/jordan-wright/email/v4) and place a new go.mod file in that subdirectory. The module path must end with /v4. Copy or move the code into the v4 subdirectory. Update import statements within the module to also use /v4 (import "github.com/jordan-wright/email/v4/…"). Tag the release with v4.x.y.

3. Suggest your downstream module users to use hash instead of a version tag.

If the standard rule of go modules conflicts with your development mode. Or not intended to be used as a library and does not make any guarantees about the API. So you can’t comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Regardless, since it's against one of the design choices of Go, it'll be a bit of a hack. Instead of go get github.com/jordan-wright/email@version-tag, module users need to use this following way to get the jordan-wright/email: (1) Search for the tag you want (in browser) (2) Get the commit hash for the tag you want (3) Run go get github.com/jordan-wright/email@commit-hash (4) Edit the go.mod file to put a comment about which version you actually used This will make it difficult for module users to get and upgrade jordan-wright/email.

*[]** You can see who will be affected here: [139 module users, e.g., cambalamas/creekmail, jacekk/go-rest-api-playground, pulsar-go/pulsar] https://github.com/search?q=github.com%2Fjordan-wright%2Femail+extension%3Amod&type=Code

Summary

You can make a choice to fix DM issues by balancing your own development schedules/mode against the affects on the downstream projects.

For this issue, Solution 2 can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.

References

KateGo520 commented 4 years ago

@JensRantil @l-ross Could you help me review this issue? Thx :p

jordan-wright commented 4 years ago

Hi there!

Thanks for sending this in. This is something I've been aware of for some time, just haven't gotten time to fix. So let's chat about it 😄

The Go docs suggest:

Note that if you are adopting modules for the first time for a pre-existing repository or set of packages that have already been tagged v2.0.0 or higher before adopting modules, then the recommended best practice is to increment the major version when first adopting modules. For example, if you are the author of foo, and the latest tag for the foo repository is v2.2.2, and foo has not yet adopted modules, then the best practice would be to use v3.0.0 for the first release of foo to adopt modules (and hence the first release of foo to contain a go.mod file).

This is why I'd lean towards doing the following:

This should get modules working where v5.0.0. While there may be some issues with certain clients like dep, it feels like it's the correct and most simple approach to more proper module support.

What do you think?

KateGo520 commented 4 years ago

@jordan-wright Thank you for your reply. You can see your downstream repos through this link: https://github.com/search?l=Go&q=github.com%2Fjordan-wright%2Femail&type=Code

And your downstream module user can be seen here: https://github.com/search?q=github.com%2Fjordan-wright%2Femail+extension%3Amod&type=Code

Downstream repos that use dep、glide and so on, can be seen here: https://github.com/search?q=github.com%2Fjordan-wright%2Femail+extension%3Ajson+extension%3Aconf+extension%3Atoml+extension%3Alock&type=Code

If you want to be compatible with all the downstream, maybe you could consider using one of two options:

  1. Delete the go.mod file when you send a commit.
  2. Create the repo using the "Major subdirectory" method

Major subdirectory: Create a new v3 subdirectory (e.g., my/module/v3) and place a new go.mod file in that subdirectory. The module path must end with /v3. Copy or move the code into the v3 subdirectory. Update import statements within the module to also use /v3 (e.g., import "github.com/my/module/v3/mypkg"). Tag the release with v3.0.0.

  • This provides greater backwards-compatibility. In particular, Go versions older than 1.9.7 and 1.10.3 are also able to properly consume and build a v2+ module created using this approach.
  • A more sophisticated approach here could exploit type aliases (introduced in Go 1.9) and forwarding shims between major versions residing in different subdirectories. This can provide additional compatibility and allow one major version to be implemented in terms of another major version but would entail more work for a module author. An in-progress tool to automate this is goforward. Please see here for more details and rationale, along with a functioning initial version of goforward.
  • Pre-existing dependency management solutions such as dep should be able to consume a v2+ module created in this way.
KateGo520 commented 4 years ago

@jordan-wright The "mixed" dependency management modes (GOPATH and Go modules) in the Go ecosysem can cause tons of issues. Having a global view of your downstream and upstream projects and their migration situations (to Go Modules) can help you select a better solution by making a trade-off analysis, which aims to avoid introducing breaking changes into other projects in the community :p

Do you agree with the above opinion?

Hope my provided information about your downstream and upstream projects are useful.

Thanks again.

Best regards.

jordan-wright commented 4 years ago

Hi @KateGo520,

Thanks for all the great feedback. I've opted to take the easy way out here for now and just removed the go.mod file. In the future, I'll consider a different option when I'm ready to cut a new major release.