版本号

你的插件应当有一个独一无二的版本号，这样其他人在下载时就可以判断哪个是新版哪个是旧版。你可以在当前流行的多种版本号规范中选一个来用。下文中将讨论这些不同规范之间的优势与劣势。

Sponge 推荐使用用 . 分割的 2～3 个数字，及连字符 - 连接的标签作为版本号，比如 3.1 或者 1.0.3-API7，这样的版本号看起来和 SemVer 相近。你的插件准备好发布的时候，版本号应从 1.x 开始。如果你的插件还很不稳定，或者没有准备发布，应从 0.x 开始。

注解

尽管 Sponge 推荐使用上述的版本号方案，但插件作者可以使用任何一种方案。惟需注意，用户可能需要面对各种五花八门的版本号，所以还请使用简单的版本号方案。

语义化版本（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 版本同时发布。

注解

SpongeAPI 使用 SemVer。

示例

  • 0.1.0

  • 1.0.0

  • 1.1.0-SNAPSHOT

  • 3.12.21-API7

优势

  • 易读易懂

劣势

  • 这套规范是 API 导向的；如果你的插件根本不提供 API，这套规范并不好使。

时间戳

这是一种少见的版本号规范，但也是一种非常简单的规范，因为它不包含任何多余信息。分隔符的选择、包含的时间与日期范围也没有限制。然而，我们建议你使用形如 YYYY-MM-DD 的形式。如果你按照字母顺序对文件排序，请确认排序后的结果和版本号顺序一致。版本号后可以包括构建类型或构建号。

示例

  • 18.01.31

  • v2018-05-29.1

  • 2018.01.13-SNAPHOT

优势

  • 易读易懂

劣势

  • 不包含任何关于兼容性的信息。

其他

关于软件版本号和版本号规范的更多内容可通过这里 <https://en.wikipedia.org/wiki/Software_versioning>了解。