Skip to main content

发布和版本政策

Backstage 项目由一系列软件组件组成，这些组件共同构成了 Backstage 平台。 这些组件既有插件，也有核心平台库和工具。 每个组件都以集合的形式发布。Packages最终，您将成为Backstage的采用者。

构成一个应用程序的Backstage软件包数量可能相当庞大，多达数百个，仅核心平台软件包就有十几个。 这就给Backstage项目的集成商带来了挑战，因为有许多移动部件和组件需要不断更新。

我们的解决方案是将我们最常用的组件及其软件包收集到一个总括版本中，我们称之为 Backstage 版本。 每个版本都是特定版本的软件包集合，这些软件包已经过验证，可以协同工作。 将其视为一个工具箱，其中包含电池，但您可以随时从开源生态系统中添加更多插件和库，也可以创建自己的插件和库。

Release Lines​

Backstage 项目有两条不同的发布线，一条是主要的 "主线 "发布线，另一条是作为下一个主线发布的预览和预发布的 "下线 "发布线。 每条发布线都有自己的发布节奏和版本政策。

主release线​

发布周期：每月发布一次，具体时间为每月第三个周三前的周二。 首次发布时间为 2022 年 3 月。

主发布行的版本包括主版本、次版本和补丁版本，但不包括不循simver版本格式为<major>.<minor>.<patch>例如1.3.0.

主版本的增量表示对Backstage平台的重大改进或改变。 它可能会带来大量新功能，或改变产品方向。 这些增量很少，也没有固定的周期。 从政策上讲，它们与次要版本没有区别。

只要不是主要版本，每个定期发布的版本都会给次要版本带来增量。 每个新的次要版本都可能包含新功能、破坏性更改和错误修复，根据版本管理政策.

补丁版本只针对重要的错误修复进行发布，并不受制于常规的发布周期，而是在需要时随时发布。

下一个发布线​

发布频率：每周，特别是每周二。

下一个版本是每周发布一次的项目版本。 使用这些版本可以让您尽早使用 backstage 中即将推出的功能。 不过，在这些版本中，有关破坏性更改的保证较少，从一个版本到下一个版本可能会引入重大的破坏性更改。

发布版本政策​

以下版本管理策略仅适用于主线版本。

  • 只有在必要的情况下，我们才会对版本>=1.0.0的软件包进行破坏性修改，目的是将影响降到最低。 在可能的情况下，我们会为破坏性修改提供弃用路径。 * 根据升级路径的简易性和漏洞的严重性，安全修复***可能会回溯到旧版本。 * 只有在最新版本中可以重现的错误报告才有效，错误修复只会应用于下一个版本。

倾斜政策​

为了使 Backstage 正常运行，必须遵守以下版本规则。 这些规则指的是软件包结构.

  • 前端应用程序核心 "中所有软件包的版本必须来自同一版本，建议将 "通用工具 "也保留在该版本中。 * 任何特定插件的Backstage依赖项都应来自同一版本。 这包括 "通用库"、"前端插件核心 "和 "前端库 "中的软件包，或者 "Backstage库 "中的软件包。 * 应用程序中不能有比 "前端应用程序核心 "软件包版本更新的软件包。 * 前端插件与相应的后端插件应来自同一版本。 后端插件的更新 ** 必须**先于或与前端插件的更新一起部署。

软件包版本政策​

每个软件包都根据simver这种版本控制与 Backstage 发布版本控制完全脱钩，这意味着您可能会有以下情况@backstage/core-plugin-api版本3.1.4成为1.12Backstage发布。

以下版本管理策略适用于所有软件包：

  • 所有公开输出的软件包都被认为是稳定的，并将在更新日志中列出一条记录 * 建议在更新日志中记录明确的升级路径。 对于新引入或不稳定的软件包，可以省略。

版本的软件包1.0.0或以上，也适用以下政策：

  • 对稳定版输出的破坏性修改必须包含一个弃用阶段(deprecation phase)。 在删除弃用版本之前，弃用版本必须已经发布了至少一个主线版本。 对 @alpha 或 @beta 输出的破坏性修改必须至少导致一个小的版本升级，并且可以不经过弃用阶段。

不被视为破坏性的更改​

有一些变更通常会被认为是破坏性变更，但我们也会破例处理。 这既是为了能够更快地发展项目，也是因为替代方案最终会对用户产生更大的影响。

对于所有实用程序应用编程接口和后端服务，只要有这意味着，对接口生产者而言，破坏合同并不被视为破坏性变更。

属于上述规则范围内的更改，必须标有**BREAKING PRODUCERS**:在更新日志中。

对于依赖注入的任何情况，在框架提供的实用程序编程接口或后端服务上添加依赖关系都不会被视为破坏性变更。 这包括任何由@backstage/app-defaults和@backstage/backend-defaults打包。

发布阶段​

release阶段(@alpha,@beta``@public)指的是TSDoc的文档标签，在每个软件包的 API 报告中也能看到。

Backstage 使用三个阶段来表示每个单独包装出口的稳定性。

  • @public - 被认为是稳定的，在主软件包入口处可用。 * @beta - 在主软件包入口处不可见，beta 输出必须通过 <package-name>/beta 或 <package-name>/alpha 导入访问。 * @alpha - 这里是龙。 在主软件包入口处不可见，alpha 输出必须通过 <package-name>/alpha 导入访问。

Node.js 发布​

Backstage "项目使用了Node.js为了明确预期，我们使用以下时间表来确定其开发工具和后端运行时Node.js 发布我们支持

  • 在任何给定的时间点，我们都支持两个相邻的偶数版本的 Node.js，例如 v12 和 v14。 一旦一个新的 Node.js 版本成为 Active LTS，我们就会切换到支持该版本和之前的版本。 切换不是立即进行的，而是尽快完成。 您可以在新应用程序的根 package.json 中的 engines 字段中找到每个版本支持的 Node.js 版本。

当我们说支持发布，这意味着

  • 使用 @backstage/create-app 创建的新 Backstage 项目将相应地设置其 engines.node 版本。 放弃与不支持版本的兼容性不被视为破坏性变更。 这包括使用新语法或 API，以及替换放弃支持这些版本的依赖关系。

TypeScript 发布​

Backstage "项目使用了TypeScript对于我们支持的 TypeScript 版本，有一个明确的政策是很重要的，因为我们希望能够采用新的 TypeScript 功能，但同时又不会破坏使用旧版本的现有项目。

TypeScript 的发布周期大约是每三个月一次。 TypeScript 版本的一个重要方面是它不遵循 semver。 特别是，它没有主版本和次版本之分，两者都是破坏性的。 一种思考方式是将两者合并，例如 4.7 版本可以被视为主版本 47，5.0 是 50，以此类推。 在这些版本中，可能会有一些补丁发布，这些补丁遵循 semver。

我们的政策是支持最近 3 个 TypeScript 版本，例如 4.8、4.9 和 5.0。 换算成时间，这意味着我们通常支持最近 6 到 9 个月的 TypeScript 版本，具体取决于我们在 TypeScript 发布窗口中的位置。 此政策适用于任何特定 Backstage 版本发布时的快照，新的 TypeScript 版本仅适用于下一个 Backstage 主线版本，而不适用于当前版本。

对于任何维护自己 Backstage 项目的人来说，这意味着您应努力至少每 6 个月升级到最新的 TypeScript 版本，否则您可能会在升级 Backstage 软件包时遇到故障。 如果您在这样做时遇到任何问题，请在主Backstage仓库中提交问题为了确保我们不会过早开始使用新的 TypeScript 功能，backstage 项目本身会使用当前支持窗口开始时的版本，在上面的例子中就是 4.8 版本。

PostgreSQL 发布​

Backstage 项目推荐并支持使用 PostgreSQL 作为持久存储。

PostgreSQL版本管理政策是每年发布一个新的主要版本，并提供新功能，然后在首次发布后支持 5 年。

我们的策略与 PostgreSQL 的版本策略一致--我们将支持最近的 5 个主要版本。 我们还将测试该范围内最新和最老的版本。 例如，如果我们目前支持的版本范围是 12 到 16，那么我们将只明确测试 12 和 16。