很多时候开发的Minecraft Mod需要同时支持多个Minecraft版本，需要独立管理版本。但是如果为每个版本单独创建一个分支，那么每次更新特性时都需要在不同分支上分别提交，即使那些更改在每个版本下具体的修改完全一致。也考虑过过将一个MC版本作为主要面向的版本，在上面开发一批特性后再合并到其他分支并以此为基础作为移植，不过真去做时又感觉分支合并时可能会引起一些难以察觉的Bug。

那么有没有一个合适的管理方案以尽可能减少跟进特性的工作量，谢谢。？

你可以设置多模块，然后让一个 'common' 模块被所有指定版本的模块所依赖
在 'common' 模块内编写共有的内容即可
Maven 和 Gradle 都支持设置模块

本帖最后由 teddyxlandlee 于 2022-8-28 20:04 编辑

版主的点子很好，然而使用common模块有一定局限性，即是你的common模块不可能脱离MC本体存在，而Minecraft本身的代码会以出人意料的方式瞎重构，你如果引入A版本的MC，你无从得知B版本的common模块能不能用。况且现有的轮子支撑不起强大的跨版本工作量，这种入不敷出的活儿可能真没必要整。
我的处理办法是：一个主线+多个支线版本，主线稳定后同步特性给支线，一步到位。
如果多个支线经营不下去，可以分析市场行情并选择放弃（比如现在基本不会有人去维护1.17的Mod，因为这个版本已经死了
如果有同时开发多平台（Forge/Fabric/Quilt）的需求，可以用现成的轮子 Architectury 全家桶，同版本的代码复用率杠杠的

Bug嘛……假的，都是特性！
人写的软件，Bug总是有的。不如找几名小伙伴组成Beta测试团队

并不推荐同时更新很多版本，因为显而易见的各版本差异大到离谱。
在这种情况下各分支独立变成了最优选了，每个版本都需要一个特别的实现方式。
就拿近的来说：1.16.4 -> 1.16.5 改变了 tag 的使用方式和世界生成的实现，这种情况下又有什么办法可以复用？
更何况 mod 开发远不止是技术上的问题，设计上也需要有些变化，1.12 -> 1.16 的变化有多大想必也不用我说了，在这种情况下如果你的 mod 毫无新意又为什么要玩 1.16 版本的而不是 1.12？更何况这期间原版经历了一次纹理更新，那你的纹理要不要改呢？这些都是 mod 开发要面临的问题。

Mod的版本管理比插件麻烦的多,基本都是抛弃式更新.