兼容性¶
版本号¶
Pier 的版本号是 <BDS 大版本>.<BDS 小版本>.<第几版>，前两段就是这一版针对的 BDS，
第三段是针对它的第几次发布。
| Pier | BDS | LeviLamina | 备注 |
|---|---|---|---|
| 26.51.2 | 1.26.51 | 26.51.5 | |
| 26.51.1 | 1.26.51 | 26.51.5 | |
| 26.40.3 | 1.26.40 | 26.40.0 | |
| 26.40.2 | 1.26.40 | 26.40.0 | |
| 26.40.1 | 1.26.40 | 26.40.0 | |
| 26.40.0 | 1.26.40 | 26.40.0 | Pre-release |
| 26.32.2 | 1.26.32 | 26.32.1 | Pre-release |
| 26.32.1 | 1.26.32 | 26.32.1 | |
| 26.20.2 | 1.26.20 | 26.20.4 | |
| 26.20.1 | 1.26.20 | 26.20.4 |
一行不是一个区间。 每个版本只对着它标明的那个 BDS 构建，换一个跑不了： Mojang 的 26.32 构建内联掉了大约三成 LeviLamina 在 26.20 上还能声明的函数， 所以 26.32 的宿主会调用 26.20 引擎没有的东西，反过来也一样。对着表格选，别在两行之间猜。
ABI 版本和发布版本是两回事¶
ABI 有自己的版本号，目前是 v2，它比发布版本号动得慢得多。新增能力只是追加一个槽， 不会推动它。
这就是按老版本 Pier 编的模组照常能用的原因：
- 新增能力是在表尾追加的槽。你的模组够不着它，也不关心。
- 删除或重排会推动
PIER_ABI_VERSION。26.32.2 做过一次：26.20.3 起废弃的四个槽 被删掉，PIER_ABI_VERSION和PIER_ABI_MIN_SUPPORTED一起推进到 2。按 v1 编的模组 在装载时被明确拒绝，而不是被放进去在之后某处崩掉，需要用 v2 的 SDK 重编。
兼容是区间不是相等：PIER_ABI_MIN_SUPPORTED <= 你的 abi_version <= 宿主的 PIER_ABI_VERSION。
模组能看到什么¶
| Rust | |
|---|---|
报 bug 时把这两个数带上。「你的 pier 太老了」这句话，只有带上它们才可操作。
SDK 替你查每一个非核心调用，并把「能力缺席」翻成一条指名道姓的错误。两种情况是分开的：
- 槽位超出表长。 宿主早于那个能力。升级 Pier。
- 槽位在表内但为空。 那个能力包没有编进这个构建。升级没用，得换一个构建。
客户端与服务端构建¶
同一份源码两边都编得过。客户端专属的槽在服务端宿主上也存在，只是为空， 所以调它得到的是一个错误，而不是编译不过。
模组面向哪个目标，写在 mod_flags 里，宿主在握手时比对 bit 0。不匹配会被明确拒绝
并说明原因——放它进来、然后在第一个只有一侧才有的槽上崩掉，是查不出来的。
可选的外部依赖¶
LegacyMoney 走延迟加载。没装它的服务器
照常启动，money 相关调用返回失败值，其余不受影响。每个调用返回什么，money 模块里写着。
什么不做保证¶
ABI 只增不减。但 Rust SDK 的 API 面可能在 Pier 版本之间变化： 一个方法可能被改名，或者一个签名被收紧，因为旧的那个让人容易犯错。 把你依赖的 tag 钉死，升级前读发布说明。