增强语义版本支持

[anemele]

Is your feature request related to a problem? Please describe.

g 没有充分利用语义版本信息，存在不便之处。例如我想从 1.20 切换到 1.22 ，但是不知道也不关心补丁版本，我期待的命令是 g use 1.22 而不是 g use 1.22.3 。

Describe the solution you'd like

构造一个哈希表，将忽略了小版本的版本号映射到小版本的最新版本，例如假设最新版本是 1.23.4 ，则 1 和 1.23 都指向 1.23.4 。
将用户输入经过哈希表转换再做后续操作，可以提升用户体验。

我用 Rust 写过一个 nodejs 的版本管理工具 nvm ，其中 src/semver.rs 包含了我的实现和测试，可以作为参考。
（我还不能用 Go 独立完成 😀）

nvm 利用语义版本信息简化输入示例：

Describe alternatives you've considered

Additional context

[voidint]

• 感谢你的建议，我也是 nvm 用户，所以你的诉求我能理解。
• 但是，go 版本并不完全遵循语义化版本号，也就是从1.21.0版本开始才有所变化。比如用户安装了1.18、1.18.1、1.18.10等多个版本，此时执行g use 1.18，这就存在二义性。

[anemele]

嗯，go 存在这个情况是之前没了解到的。

我有两个思路：

一是设置一个选项（例如一个环境变量）来控制该行为，默认 disabled 。既然新发布的 go 遵循语义版本号，那些只用最近发布版本的用户可以 enable 该功能，而需要兼顾老版本的用户不受影响。

二是做冲突检测，如果冲突，则提示用户选择，否则正常使用该功能。

[voidint]

• 引入新的环境变量或者命令行选项方式来去除二义性，这我并不赞同。引入某个机制来解决问题，前提是这个机制带来的成本得低于这个待解决问题本身，不然都得不偿失了。
• 让用户二次输入的方式也并不理想。
• 你描述的第一种方式也有可以借鉴的地方：当输入的模糊版本号（暂且这么称呼）大于等于1.21时，自动切换本地已安装的该版本的最新版本；否则，严格按照指定的版本号进行切换。这种方式我觉得可以考虑。

[anemele]

我又仔细查看了 go 发布的所有版本号，存在二义问题的只有 1.21.0 之前的版本，本应是 1.x.0 的却是 1.x 。

以我浅薄的经验，实际情况中，使用老版本基本都是使用最新的补丁版本，冲突发生概率极小。

我还是认为，如果发生冲突，给用户提示并做出选择是一种理想的解决方案。例如我本地安装有 1.18 和 1.18.x （x 未知），如果我想从 1.23.4 切换到 1.18.x ，我可以直接 g use 1.18 ，检测到冲突后，程序给出选项（只有两个），我做出选择完成切换；使用当前的程序面对这种情况的做法是先 g ls 获知 x ，然后 g use 1.18.x ，实际上也是输入两次。二者对比，我认为前者对用户更友好。🤔

综上来看，处理一个低概率冲突，以换取用户体验是值得的。