xjasonlyu / tun2socks

tun2socks - powered by gVisor TCP/IP stack
https://github.com/xjasonlyu/tun2socks/wiki
GNU General Public License v3.0
3.14k stars 433 forks source link

Fix: use major version suffixes #88

Closed linfan closed 2 years ago

linfan commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

Thanks again.