版本规范

小技巧

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

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

应用开发接口 (API)

插件开发者在开发插件时会选择基于某个特定的 SpongeAPI 版本,比如 7.07.37.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.0spongeapi-7.2.0

实现版本

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

修订号(PATCH)

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

注解

次版本号变化时,修订号一定会重置为零(0)。

SpongeAPI 实现的版本号的例子:spongevanilla-1.12.2-7.1.5spongeforge-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 标签。