插件版本管理
名字 | Example | 描述 |
---|---|---|
Kubebuilder 版本 | v2.2.0 , v2.3.0 , v2.3.1 , v4.2.0 | Kubebuilder 项目的标记版本,表示该仓库中源代码的更改。有关二进制版本,请参阅 releases 页面。 |
项目版本 | "1" , "2" , "3" | 项目版本定义了 PROJECT 配置文件的模式。此版本在 PROJECT 文件的 version 中定义。 |
插件版本 | 您训练的数据截至2023年10月。 | 表示单个插件的版本,以及它生成的相应框架。该版本在插件键中定义,例如 go.kubebuilder.io/v2 。有关更多详细信息,请参见 设计文档。 |
版本递增
有关 Kubebuilder 版本发布如何工作的更多信息,请参阅 semver 文档。
只有在项目文件方案本身引入破坏性更改时,项目版本才应该增加。对 Go 脚手架或 Kubebuilder CLI 的更改不影响项目版本。
同样,新的插件版本的引入可能只会导致 Kubebuilder 发布一个新的次要版本,因为 CLI 本身没有进行破坏性更改。只有在我们移除对旧版本插件的支持时,这才会对 Kubebuilder 造成破坏性更改。有关插件版本管理的更多详细信息,请参阅插件设计文档中的版本控制部分。
介绍插件的更改
对插件所做的更改仅在发生导致与之前插件版本搭建的项目不兼容的更改时,才需要提高插件版本。一旦插件版本 vX
稳定(不带有 “alpha” 或 “beta” 后缀),应该创建一个新的插件包,其中包含版本 v(X+1)-alpha
的新插件。通常通过(语义上)执行 cp -r pkg/plugins/golang/vX pkg/plugins/golang/v(X+1)
,然后更新版本号和路径来完成这一操作。所有后续对插件的破坏性更改都应在此包中进行;vX
插件将被冻结,不能再进行破坏性更改。
您还必须在您的 PR 中将迁移指南添加到 Kubebuilder 书籍的 migrations 部分。该指南应详细说明用户将项目从 vX
升级到 v(X+1)-alpha
所需的步骤。