我们正在调整发布策略,以更严格地遵守语义化版本控制。未来,稳定开发表面(即正式发布)中的破坏性变更将仅在主版本迭代中推出。

TL;DR
以下是我们正在实施的新规则的简要概述
- 通过采用 SemVer,我们使用户更容易理解哪个版本可能包含破坏性变更。采用 SemVer 仅仅是我们发布策略的更改,使其与行业实践保持一致并改善开发者体验。
- 稳定表面(即正式发布)中的破坏性变更将仅在新主版本中引入。
- 破坏性变更仍然可以在次版本中推出,但仅限于默认不激活的可选预览版和早期访问功能(例如,通过预览功能标志或特定的选择加入选项或新的 CLI 命令)。
- 在次版本中发布的可选破坏性变更,即预览版和早期访问版,将仅在新主版本中升级到正式发布(无需选择加入)。
您可以在我们的文档中“发布和成熟度级别”部分阅读有关此内容的更多详细信息。
Prisma 版本采用 SemVer
语义化版本控制 (SemVer) 是一种传统的发布策略,它对用户何时可以预期软件版本中的破坏性变更制定了明确的规则。
虽然我们已经为 Prisma 版本遵循了 3 位数的 SemVer 表示法,但我们尚未完全遵循实际的 SemVer 语义。这意味着我们有时会在次版本迭代时发布破坏性变更。
未来,次版本迭代中的破坏性变更将始终是可选的。对 Prisma ORM 稳定开发者表面的任何破坏性变更都将仅在主版本迭代中发生。
目前,用户很难理解哪个版本可能包含或不包含破坏性变更。当通过多个版本升级时,例如从 2.13.0
升级到 2.26.0
,您必须阅读每个中间版本的发布说明,以确定哪些破坏性变更会影响您——这使得导航破坏性变更变得困难。
这对您意味着什么?
本质上,新的发布策略不会改变您使用 Prisma 的方式以及 Prisma 的持续发展。我们只是让您更容易理解哪个版本可能包含破坏性变更。
Prisma 将继续在发布说明中记录即将到来的破坏性变更的确切细节。此外,我们将提供升级指南,以帮助您完成主版本之间的升级路径。
行业中的许多包管理器和依赖项自动化工具在设计时都考虑了 SemVer,例如 Renovate 和 Dependabot。它们通过自动化依赖项升级过程的某些部分、创建包含相关版本更改的拉取请求以及自动合并非破坏性变更来节省您的时间。
为什么我们采用 SemVer 语义
更新依赖项可能是一个耗时的过程——尤其是在具有许多依赖项的项目中。 遵守 Semver 应该可以改善您的升级体验,因为破坏性变更在未来会变得可预测和可见。
SemVer 是一种广泛使用的行业标准,尤其是在 Node.js 生态系统中。
随着我们看到越来越多的开发者和公司采用 Prisma,并收到关于我们发布策略的有用反馈,我们已决定调整我们的发布策略,并在未来完全采用 SemVer。
Prisma 即将发布的一个版本将包含破坏性变更
Prisma 即将发布的一个 版本将包含破坏性变更。根据我们的新发布策略,主版本号将递增,因此 Prisma 的新版本将为 3.x.x
。
您可以在文档中阅读有关我们发布策略的更多信息。
不要错过下一篇文章!
注册 Prisma 新闻通讯