-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot get latest version: module contains a go.mod file, so module path should be github.com/ipfans/echo-session/v4 #25
Comments
@Atrox Could you help me review this issue? Thx :p |
Can you end a pull request for this issue? |
Hey @KateGo520, IMHO this is a non-issue. Many go libraries that migrated to go modules with a version greater than v1 have their go.mod without a version suffix. This makes the migration process for the library and dependent projects easier. If echo-session should reach v5 at some point then the go.mod should specify the /v5 suffix. I don't see why you would try to install echo-session with the /v4 suffix when the README clearly states how you should go-get it (without the suffix). I use echo-session without issues in all my projects (all on go modules). If you now decide that there should be an /v4 suffix, this is a breaking change and has to be done to a v5 which in turn means it is a /v5 suffix in the end. I hope this clears up the reasoning behind the v4 currently having no /v4 suffix. Thanks, |
@Atrox Thanks for your reply. I get it. |
@Atrox Follow the README direction, I run
|
Background
The
github.com/Ipfans/echo-session
uses Go modules and the current release version isv4
. And it’s module path is"github.com/Ipfans/echo-session"
, instead of"github.com/Ipfans/echo-session/v4"
. It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:Steps to Reproduce
GO111MODULE=on, run
go get
targeting any version >= v4.0.0 of theIpfans/echo-session
:Run
go get github.com/Ipfans/echo-session
, the version will stuck in v3.2.0:So anyone using Go modules will not be able to easily use any newer version of
Ipfans/echo-session
.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
I see these dependencies in your go.mod file, which need modle awareness. So you'd better not use third-party tools(such as: Dep, glide, govendor…).
You also need to update the import path to:
2. Fix module path to strictly follow SIV rules.
Patch the
go.mod
file to declare the module path asgithub.com/Ipfans/echo-session/v5
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: [3 module-unaware user, i.e., Soontao/go-simple-api-gateway, xuybin/go-api-gateway, webinone/VCMS-GITHUB]
https://github.com/search?q=github.com%2Fipfans%2Fecho-session+filename%3Avendor.conf+filename%3Avendor.json+filename%3Aglide.toml+filename%3AGodep.toml&type=
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 v5
subdirectory
(github.com/Ipfans/echo-session/v5) and place a new go.mod file in that subdirectory. Themodule path
must end with/v5
. Copy or move the code into the v5 subdirectory. Updateimport statements
within the module to also use/v5
(import "github.com/Ipfans/echo-session/v5/…"). Tag the release withv5.x.y
.3. Suggest your downstream module users 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/Ipfans/echo-session@version-tag
, module users need to use this following way to get theIpfans/echo-session
:(1) Search for the
tag
you want (in browser)(2) Get the
commit hash
for thetag
you want(3) Run
go get github.com/Ipfans/echo-session@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
Ipfans/echo-session
.[*] You can see who will be affected here: [13 module users, e.g., sasa-nori/nyaitter, elwin/heatmap, gotomsak/fe-learning-back]
https://github.com/search?l=&o=desc&q=github.com%2Fipfans%2Fecho-session+filename%3Ago.mod&s=indexed&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
The text was updated successfully, but these errors were encountered: