版本号
您的插件应当有一个独一无二的版本号，这样其他人在下载时就可以判断哪个是新版哪个是旧版。您可以在当前流行的多种版本号规范中选一个来用。下文中将讨论这些不同规范之间的优势与劣势。
我们推荐使用用 . 分割的 2 到 3 个数字，及连字符 - 连接的标签作为版本号，比如 3.1 或者 1.0.3-rc，这样的版本号看起来和 SemVer 相近。您的插件准备好发布的时候，版本号应从 1.x 开始。如果您的插件还很不稳定，或者没有准备发布，应从 0.x 开始。
对于上述版本号的约定我们只是提供建议。需要注意的是，用户可能需要面对各种五花八门的版本号，所以还请使用简单的版本号方案。
语义化版本（SemVer）
语义化版本 (SemVer) 是一种常用的语义化版本号规范。它由三个由点（.）分割的数字部分，及由连字符（-）连接的额外标签组成。三个数字部分分别是 MAJOR、MINOR 和 PATCH 版本号。
- 对
MAJOR版本号变更代表您对 API 进行了不兼容的改动。大规模重写，或完全重写 整个插件也算入此列。 - 对
MINOR版本号的变更代表您新增了某种功能，但仍然保持了向后兼容。 - 对
PATCH版本号变更代表您进行了 bug 修复。
标签可用于标记预发布版本，或用来标记构建的元数据，比如支持的 Minecraft 版本这样的信息。如果某一个版本数字递增了 1，那么其后面的部分都应重置为 0。使用这套策略您可以判断哪一个版本是最新的版本，但它并不能透露任何关于发布时间的信息，比如 1.0.9 版本可能会在 1.0.8 版本之后发布，但此时 1.1.0 版本可能在这之前或之后发布，甚至是与 1.0.9 版本同时发布。
TabooLib 和 SpongeAPI 都使用了 SemVer。
示例
1.0.0: 第一个正式版本。1.0.1: 修复了一个 bug。1.1.0: 新增了一个功能。2.0.0: 对 API 进行了不兼容的改动。
优势
- 易读易懂。
劣势
- 无法透露发布时间。
- 这套规范是 API 导向的；如果您的插件根本不提供 API，这套规范并不好使。
时间戳版本
这是一种少见的版本号规范，但也是一种非常简单的规范，因为它不包含任何多余信息。分隔符的选择、包含的时间与日期范围也没有限制。然而，我们建议您使用形如 YYYY-MM-DD 的形式。如果您按照字母顺序对文件排序，请确认排序后的结果和版本号顺序一致。版本号后可以包括构建类型或构建号。
示例
21.07.01v2021-07-21.12021.07.21-SNAPSHOT
优势
- 易读易懂。
劣势
- 不包含任何关于兼容性的信息。