Skip to content

Fix: use major version suffixes #88

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Jan 3, 2022
Merged

Fix: use major version suffixes #88

merged 1 commit into from
Jan 3, 2022

Conversation

linfan
Copy link
Contributor

@linfan linfan commented Dec 23, 2021

According to the go module convention, if the module is released at major version 2 or higher, the module path must end with a major version suffix like /v2. This may or may not be part of the subdirectory name.

Therefore currently the v2 version of this repo can neither be fetched via go get command nor be referred in go.mod:

$ go get github.com/xjasonlyu/tun2socks      # without version will only fetch v1 code
go get: added github.com/xjasonlyu/tun2socks v1.18.3

$ go get github.com/xjasonlyu/tun2socks@v2.3.2      # specify v2 version will cause error
go get: github.com/xjasonlyu/tun2socks@v2.3.2: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

To demonstrate the effect, I had made a quick fork and put a v2.3.2-fix to my repo, and below command would work as expected:

$ go get github.com/linfan/tun2socks/v2@v2.3.2-fix       # it works

@xjasonlyu
Copy link
Owner

Many thanks for this PR, which reminds me the go get issue. I do understand the go official regulations about the module-path, but I hesitated to add the v2 suffix before. Here's the origin:

Initially, this project was a modified version of eycorsican/go-tun2socks, but then I decided to start a new one, which is the current tun2socks project.

In order to distinguish this project from previous modified one, I have to start tagging it from v2. Technically, however, it's not a second version of tun2socks but an actual first version, since it has nothing to do with the "version 1" except the name.

Therefore, I wonder if there's any other ways to solve this problem.

Sorry for the confusion.

@xjasonlyu
Copy link
Owner

Or, I can remove all the v1.x.x and rename all the v2.x.x tags to v1.x.x, but it's gonna be very weird lol.

@linfan
Copy link
Contributor Author

linfan commented Dec 24, 2021

Since no one could refer to those v2 version packages so far, renaming them to v1.x.x is surely a workable solution.

But why not just fix the package naming and become real v2, as it's already a "modified one" of the original v1.
Over shoes, over boots : )

@xjasonlyu
Copy link
Owner

Since no one could refer to those v2 version packages so far, renaming them to v1.x.x is surely a workable solution.

Actually, v2 version can be referred like pkg@commit.

But why not just fix the package naming and become real v2, as it's already a "modified one" of the original v1.
Over shoes, over boots : )

Oh haha, because I have another private v2 development ongoing. =)

@linfan
Copy link
Contributor Author

linfan commented Dec 27, 2021

Actually, v2 version can be referred like pkg@commit.

It works with go get, but not for go.mod.

Because I have another private v2 development ongoing.

That's another story then, how about v3 for this public one ; )

@xjasonlyu xjasonlyu merged commit c068fbd into xjasonlyu:main Jan 3, 2022
@xjasonlyu
Copy link
Owner

I revised my private one, v2 is good to go now😉.

Thanks again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@linfan @xjasonlyu