新的版本号可能导致问题

[Fangliding]

golang的版本号不是随便写的 主版本号（第一位）意味着很大和破坏性的更新 这不只是约定俗成的 还是一个有意义的东西
更改主版本之后被视为一个新的模块 现在的 github.com/xtls/xray-core/xxx 里的东西全部需要被更名为 github.com/xtls/xray-core/v24/xxx
否则go get会炸掉 现在尝试go get 24.9.30版本会失败 pkg.go.dev 也不会正常更新了 见这里 #3874 (comment)
现在有两个选择
一是 重命名模块(以及修改项目里面所有go文件的引用)并每年做一次类似的事 然后引用xray的下游也每年炸一次
二是 撤回修改 重新改用 1.x.x 的版本号
@RPRX @yuhan6665

[yuhan6665]

现在的方案是 go module 版本号死在 1.8.x 然后项目版本号随便改
不是很方便 但是也有不少这样的例子 比如 gvisor

[yuhan6665]

这里可以查到新版本
https://deps.dev/go/github.com%2Fxtls%2Fxray-core

[povsister]

说golang的版本我还以为是gomod里go/toolchain的版本..
这个应该是叫gomod release versioning，如果按照gomod的要求，以后xray确实会每年“break”一次。
https://go.dev/blog/v2-go-modules

要么就core发行抽出来单独做，否则源代码上打tag做release确实会和gomod干起来

[RPRX]

两个都不选，一天天的搞得像发现了新大陆一样

@yuhan6665 和我早就研究过这个问题了，v24.9.7 写了“Import 参考 2dust/AndroidLibXrayLite#58 ”

[RPRX]

之前试过了在 require Xray-core 后 +incompatible 也不行，希望 Go 以后会给出个方式，允许项目本身自己声明 incompatible

[RPRX]

看了下群，群里说的 v1.24 的方案之前也想过，但是是四个数比如 v1.24.9.7，REALITY 也支持，但已经 release v24.9.7 了就算了

而且这样的话看起来版本号升得太慢，release 新版本的成就感大打折扣，用户也会潜意识觉得没更新什么