大卫·惠勒：扩展版本控制的历史与未来
内容提要
设计PGXN时决定采用语义版本（SemVer）作为版本标准，所有元数据都在META.json文件中，验证简单。建议继续使用语义版本作为扩展分发的标准。
延伸解读
PostgreSQL核心的版本命名约定
PostgreSQL核心通过文件命名约定（如pair--1.1.sql）来管理扩展版本，将版本标准的责任完全交给扩展作者。这种方式避免了核心对版本排序和升级逻辑的强制要求，但也意味着版本管理完全依赖作者的自觉性。对于需要自动处理版本的系统（如PGXN），这种约定无法提供可靠的版本比较和验证机制。
PGXN为何选择SemVer
PGXN要求所有元数据集中在META.json中，并采用SemVer作为版本标准。SemVer的明确排序规则使得版本验证变得简单，例如允许在1.3.0之后发布1.2.3来维护旧分支，但不能发布1.2.1。这种灵活性在CPAN模型基础上进行了调整，适应了实际发布需求。
其他版本管理方案的对比
文章调查了2024年常见的版本管理方法：临时版本（如CRAN）依赖作者按顺序发布，容易造成混乱；用户自选（如Python、CPAN）虽灵活但可能引发混淆；CalVer（如Ubuntu）将日期融入版本，但可与SemVer兼容；包管理器（如RPM、Apt）不强制上游版本标准。相比之下，SemVer在清晰度和工具支持上更胜一筹。
对PostgreSQL社区的推荐
基于对多种版本方案的调查，作者建议PostgreSQL社区继续采用SemVer作为扩展分发的标准，与Go、Rust、npm等现代注册中心保持一致。尽管SemVer与核心的宽松要求存在对比，且CalVer支持者可能受限于格式（如禁止前导零），但SemVer的广泛采用和日期语义支持能力使其成为最合理的选择。
Q&A
PGXN 为什么选择语义版本（SemVer）作为扩展的版本标准？
PGXN 在设计早期就决定要求使用语义版本，因为它是一个定义清晰且被广泛采用的版本标准。语义版本简化了版本管理，其明确的排序规则使得版本验证变得简单，并且允许更新已发布的版本。
PostgreSQL 扩展的版本管理是如何通过文件命名约定实现的？
PostgreSQL 要求扩展作者遵循文件命名约定，例如扩展名为“pair”且版本为1.1时，文件名为“pair--1.1.sql”。升级时提供类似“pair--1.1--1.2.sql”的文件。只要文件名正确且版本部分与控制文件中的条目字节兼容，CREATE EXTENSION 就能找到它。这种方法避免了版本标准化和排序的问题，将责任完全交给扩展作者。
PGXN 对扩展的元数据有什么要求？
PGXN 要求所有扩展的元数据都放在 META.json 文件中，而不是从其他可能变化的来源派生。这确保了元数据的集中和一致性。
如果扩展使用与 SemVer 不兼容的版本标准，PGXN 如何处理？
PGXN 只关心 META.json 文件的内容，因此扩展可以在控制文件中使用自己的版本标准（如两部分的 x.y 版本），只要 META.json 文件使用语义版本即可。例如，nominatim_fdw 在控制文件中使用 default_version = '1.0'，但在 META.json 中写为 "1.0.0"。
2024 年有哪些常见的版本管理方法？
2024 年常见的版本管理方法包括：临时版本（Ad Hoc Versions）、用户选择（User Choice）、语义版本（SemVer）和日历版本（CalVer）。临时版本允许任意版本号，但可能导致混乱；用户选择允许用户自选标准，但通常推荐 SemVer 或 CalVer；SemVer 被许多现代注册表采用；CalVer 将日期嵌入版本号。
大卫·惠勒对 PostgreSQL 社区的版本管理有什么建议？
他建议 PostgreSQL 社区遵循 PGXN 以及 Go、Rust 和 npm 的先例，继续依赖并要求语义版本进行扩展分发。尽管 SemVer 并不完美，但它的持续采用、被广泛使用的注册表要求以及支持基于日期的语义的能力，使其仍然是最合理的选择。
