版本命名

在一般的工程当中, 通常使用语义化版本(Semantic Versioning)，其格式为主版本号.次版本号.修订号(MAJOR.MINOR.PATCH)。然而，对于mod的场景来说，使用MC版本-MOD主版本号.API主版本号.次版本号.修订号 (MCVERSION-MAJORMOD.MAJORAPI.MINOR.PATCH)会更好一点。因为这能够区分一个mod的世界不兼容和API不兼容的改变。

示例

这里是一个（不完全的）列表，它告诉你什么时候该递增不同的变量。

• MC版本(MCVERSION)
  • 总是与该mod工作的Minecraft版本对应
• MOD主版本号(MAJORMOD)
  • 删除物品、方块、TileEntity等
  • 改变或者删除之前存在的机制
  • 更新到新的Minecraft版本
• API主版本号(MAJORAPI)
  • 改变Enum的顺序或者变量
  • 改变方法的返回值
  • 删除public方法
• 次版本号(MINOR)
  • 添加物品，方块，TileEntity等
  • 添加新的机制
  • 不建议使用（译注：添加@Deprecated标注的）public方法（这不是一个API主版本号的递增，因为它并没有使API不兼容）
• 修订号(PATCH)
  • 修复Bug

当递增任意一个变量，比它次要的变量都应重置为 0。例如，如果次版本号递增了，修订号将会变成 0； 如果MOD主版本号递增了，剩下的所有变量都要变成 0。

正在进行的开发

如果你正在你的mod开发的初始开发阶段（在官方发布之前），MOD主版本号和API主版本号都应该是 0。只有次版本号需要在你每次构建的时候更新。一旦你构建了官方的发布(通常有一个稳定的API)，你需要将你的MOD主版本号递增至 1.0.0.0。对于更深入的开发阶段，请看预发布和候选发布部分。

多个Minecraft版本

如果mod升级到了一个新的Minecraft版本，并且旧版本只会得到bug修复，修订号需要在升级之前根据版本更新。如果mod仍然同时对新旧两个Minecraft版本活跃开发，我们建议您在两个版本号前都加上Minecraft的版本。例如，如果mod因为新版本Minecraft升级到了 3.0.0.0，旧的mod也应该升级到 3.0.0.0。例如，旧的版本将会是 1.7.10-3.0.0.0，而新的版本是 1.8-3.0.0.0。如果在升级到新的Minecraft版本的时候代码没有任何变动，所有的变量（除了Minecraft版本）都应该保持不变。

最终版本

当对一个Minecraft版本放弃支持时，对于这个版本的最后一个构建应该加上一个 -final 后缀。这说明该MC版本的mod将不会得到支持，玩家需要升级到更新的mod版本才能继续收到更新和bug修复。

预发布

预发布一个正在进行开发的特性也是可能的，也就是说新特性在没有完全完成之前被发布。这也可以被看做是beta版本。这些版本需要加上 -betaX 的后缀，X是预发布的数量（这个指南没有使用 -pre 因为，在写作的时候，根据Forge它并不是一个合法的-beta的别名）。注意已经发布的版本和还没有进行初始发布的版本不能够进入预发布。在添加 -beta 后缀前，变量（通常是次版本号，但是API主版本号和MOD主版本号也可以进行预发布）应该被对应地更新。在初始发布的版本前应该简单地使用正在开发的(WIP)构建。

候选发布

候选发布版本在一个正式的版本变化前充当预发布版的作用。候选发布版本应该加上 -rcX 的后缀，其中X候选发布的数量，它理论上只能在bug修复时候被递增。已经发布的版本不能有候选发布版。在添加 -rc 后缀前，变量（通常是次版本号，但是API主版本号和MOD主版本号也可以进行候选发布）应该被对应地更新。当将一个候选发布版本发布为一个稳定的构建时，它可以是与最后一个候选发布版本完全一样的构建也可以是添加了一些bug修复的版本。