版本与治理

版本号是兼容承诺，不是发布装饰。治理决定谁可以修改承诺、如何评审安全边界，以及实现者如何判断某个版本是否仍受支持。

协议版本

当前值为 pling.surface/0.1。版本出现在每个请求与响应中，客户端必须精确匹配。

• 补丁修订用于澄清、测试和文档修正，不改变线协议行为；
• 次版本可以增加向后兼容的可选字段或方法；
• 主版本用于删除字段、改变语义、改变默认授权行为或引入不兼容错误。

在 1.0 之前，协议仍可能变化。任何不兼容变化必须提升版本值，并让旧客户端得到 PROTOCOL_VERSION_UNSUPPORTED 或明确的方法错误，不能静默按旧含义执行。

扩展规则

扩展必须满足：

1. 旧客户端不认识时可以安全忽略；
2. 不改变既有字段的含义；
3. 不把安全判断下放给客户端；
4. 有独立错误码或能力标识；
5. 有测试向量和回滚方案。

私有扩展可以在部署内使用，但不得声称属于 0.1 标准。影响授权、审计或审批的扩展尤其需要公开说明。

弃用流程

移除能力或字段应经过：

公开提案 → 影响与安全评审 → 实现兼容路径
→ 发布弃用说明与迁移指南 → 至少一个稳定周期
→ 主版本移除

弃用说明必须列出旧行为、替代方案、最后支持版本与迁移失败模式。不能只在代码注释里标记 deprecated。

治理

在项目形成稳定采用前，治理应保持小而透明：

• 公开变更提案与讨论记录；
• 说明维护者、决策方式与利益冲突；
• 安全变更由具备相关经验的人复核；
• 协议文本、参考实现与一致性测试分开版本；
• 认证、商标与商业支持不得被描述为协议本身的必要条件。

当前没有独立基金会、技术指导委员会或认证机构。任何未来治理结构应通过公开文档建立，不能追溯性地把现有草案称为已批准标准。

兼容矩阵

每个发布应说明：

项目	需要记录
协议	支持版本、未知版本行为
包	版本、运行时与框架要求
传输	参考实现与未支持能力
安全	限流、重放、审计、撤销的实现状态
证据	测试命令、夹具、日期与已知缺口

兼容性声明必须与证据范围一致。只在单一浏览器或内存适配器上通过，不得写成跨环境保证。

许可证

代码采用 Apache-2.0。协议文本计划采用 CC-BY-4.0，参考实现与一致性测试采用 Apache-2.0。该区分允许广泛实现，同时保留文本署名要求。许可证不构成安全认证，也不授予 Pling 商标使用权。