版本规范

小技巧

Sponge 的版本号使用一种符合语义化版本（SemVer）规范的格式。关于 SemVer 的一般用法可参考 https://semver.org/。

SpongeAPI 及其实现（SpongeForge 和 SpongeVanilla）使用两套不同的规则。只需要按 SemVer 的规范解读即可了解我们使用的版本号的含义。SpongeAPI 使用了 SemVer 中的“主版本号”（MAJOR）和“次版本号”（MINOR）两部分，而 SpongeForge 和 SpongeVanilla 相比于 SpongeAPI 还多使用了“修订号”（PATCH）。

应用开发接口 (API)

插件开发者在开发插件时会选择基于某个特定的 SpongeAPI 版本，比如 7.0、7.3 或 7.9，如此一来这个插件能在那个版本上工作。SpongeAPI 版本的变化反映了特性的增删与修改，版本变化的方式也反映了插件受影响的程度。

主版本号（MAJOR）

主版本（X.Y.Z）的变化代表了 API 的破坏性更新。插件有可能会因此无法在新版 API 上工作。比如说，某个基于 SpongeAPI 6.9 开发的插件有可能无法在 SpongeAPI 7.0 上正常工作。

次版本号（MINOR）

次版本（X.**Y**.Z）的变化代表了新的 API 特性的出现，同时基于有相同主版本号的旧版 SpongeAPI 开发的插件仍然能工作，举个例子，某个基于 SpongeAPI 7.3 开发的插件仍然可以在 SpongeAPI 7.4 或者 7.5 上工作，但反过来不一定成立（即基于 7.4 开发的插件不一定能在 7.3 上工作）。

注解

主版本号变化时，次版本号一定会重置为零（0）。

SpongeAPI 版本号的例子：spongeapi-7.1.0、spongeapi-7.2.0。

实现版本

Sponge 具体实现的版本包含了目标 Minecraft 的版本及 SpongeAPI 的版本。SpongeForge 在此基础上还包括了保证兼容性的 Forge 的推荐版本。

修订号（PATCH）

修订号（X.Y.**Z**）的变化只出现在具体实现的构建中，代表了某个具体实现的漏洞修复、性能调优、配置变更及其他和 API 无关的变化。若修订号只是一个数字，则该版本是一个推荐版本。所有基于该版本所包含的 SpongeAPI 版本（即 X.Y 部分）开发的插件及兼容的插件都能在该版本实现上运行。

注解

次版本号变化时，修订号一定会重置为零（0）。

SpongeAPI 实现的版本号的例子：spongevanilla-1.12.2-7.1.5、spongeforge-1.12.2-2768-7.1.5。

警告

插件开发者可以选择基于某个特定的 SpongeAPI 实现开发插件。若如此做，该插件的 Ore 页面上应有对应的标签反映这个决定，且 Sponge 此时无法对该插件兼容性做任何保证。

快照（SNAPSHOT）

带 -SNAPSHOT``（“快照”）标签的构建代表了正在开发中的下一个 API 发布版本。比方说 ``7.2.0-SNAPSHOT 代表了正在开发中的 7.2.0 版本。再比如 8.0.0-SNAPSHOT 代表了正在开发中的下一个主要更新 8.0.0。快照版本中的新特性随时都有可能停止工作。

注解

若次版本号是零（比如 8.0-SNAPSHOT），那么这个版本中的所有特性在正式发布之前随时都有可能停止工作，插件此时不应指望有任何稳定性可言。若次版本号不是零（比如 7.2-SNAPSHOT），那么直到上一个次版本号（对于刚才的例子来说是 7.1）的所有版本中的特性都仍然保证正常工作，但接下来的更新中则有可能导致部分特性停止工作，不稳定性也会随之上升。

当次版本号和修订号皆为零，且有 -SNAPSHOT 标签存在时，这个版本是用于测试下一个 SpongeAPI 主要版本的 bleeding 构建，随时有可能出问题。

SpongeCommon 上的 -SNAPSHOT 标签代表该实现已接近完成，但作为下一个发布来说仍然不够稳定。更重要的是，Gradle 会根据这个标签是否存在来决定是否追加 -RC{构建号} 的标签。

候选发布版本（Release Candidate，RC）

所有推送到 GitHub 上的更新，若不构成推荐版本，则代表一个“候选发布版本”（Release Candidate）。在经过进一步测试后它有可能会成为下一个推荐版本。推荐版本也有可能工作不正常。

小技巧

SpongeAPI 和 SpongeCommon 会有 SNAPSHOT 标案，而两个具体实现则是会有 RC 标签。