主要观点：

• 不能用semantic-release发布 0.x.y 版本，需使用语义化版本的预发布版本，应将发布 0.x.y 版本设为默认，而非直接发布 v1 稳定版。
• 过早确定稳定 API 可能受限，不知用户需求时贴“稳定”标签不真诚，设计接口困难，应给未来留调整空间。
• 版本是沟通工具，发布 0.x.y 版本可向用户表明未提供稳定 API，通过发布说明突出破坏变更，这是语义化版本的一部分，利于软件进化。
• 对于库或工具 API 适用此观点，Web API 则不同，决策时需权衡用户升级负担和维护者限制，不必一定发布 v1，发布 v1 是大事。

关键信息：

• semantic-release限制发布 0.x.y 版本，需用预发布版本。
• 不知用户需求时过早确定稳定 API 受限，设计接口困难应留调整空间。
• 版本是沟通工具，发布说明可突出破坏变更，是语义化版本一部分利于进化。
• 库或工具 API 适用，Web API 不同，决策需权衡，不必一定发布 v1，发布 v1 是大事。

重要细节：

• 如发布oapi-codegen/nullable时过早确定 v1.0.0 导致需后续修改，若为 v0.1.0 可先获取反馈再确定。
• 设计接口时要避免“画地为牢”，给未来留调整空间，如 Stripe 支持多年 API 版本。
• 发布说明可用于突出破坏变更，如go-semantic-release驱动的dependency-management-data的发布说明。
• 不同用户对发布说明的阅读程度不同，即使详细记录也不一定被阅读。
• 语义化版本规范最初就有 0.x.y 版本，应利用此部分。
• 库可保持“不稳定”API 以便理解“稳定”含义，控制地进行破坏变更利于进化。
• 对于库或工具 API 讨论较多，Web API 推送不兼容变更困难。
• 决策时需考虑复杂度，“不稳定”API 让用户承担升级负担，“稳定”API 限制维护者。
• 发布 v1 是大事，如 OpenPolicyAgent 团队历经 9 年达到可发布 v1 的状态。