版本控制和稳定性保证
由于创新有时需要引入大胆和广泛的更改，这可能会影响 k6 用户的工作流程，因此我们的目标是确保 k6 所有用户的稳定性、可预测性和易用性，包括在云端利用 k6 以及基于开源项目构建的其他产品的用户。
在以下章节中，我们将定义适用于 k6 软件（从 v1.0.0 版本开始）的工作流程、保证和限制。
注意
本文档作为明确的允许列表政策。只有本文档中明确提及的 API 才受我们的稳定性保证覆盖。任何未明确包含的 API 不在此政策覆盖范围内，可能会受到破坏性更改的影响。
如果你认为某个 API 应该被添加到此允许列表但目前缺失，请在 k6 仓库中提出新的 issue，以便就其潜在包含进行讨论。
版本控制策略
k6 严格遵循语义化版本控制 2.0.0 规范。此版本控制规范定义了三种软件版本，并根据它们与核心概念“破坏性更改”的关系进行分类。
破坏性更改
根据语义化版本控制 2.0.0 规范，我们将破坏性更改定义为对 k6 进行的不向后兼容的更改。
破坏性更改意味着 k6 的使用者需要做一些努力来适应所做的更改。
主版本
主版本包含向后不兼容的 API 更改。
主版本 X (X.y.z | X > 0) 在向公共 API 引入任何向后不兼容的更改时 **必须** 递增。这可能也包括次要版本和补丁版本更改。当主版本递增时，补丁版本和次要版本 **必须** 重置为 0。
虽然包含破坏性更改的新主版本可能仍然与之前版本兼容，但这不应该被预期。
次版本
次版本包含向后兼容的 API 添加/更改。
次版本 Y (x.Y.z | x > 0) 在向公共 API 引入新的、向后兼容的功能时 **必须** 递增。如果在任何公共 API 功能被标记为已弃用时 **必须** 递增。在私有代码中引入实质性新功能或改进时 **可以** 递增。它 **可以** 包括补丁版本更改。当次版本递增时，补丁版本 **必须** 重置为 0。
补丁版本
补丁版本包含**不影响** API 的错误修复。
补丁版本 Z (x.y.Z | x > 0) 在只引入向后兼容的错误修复时 **必须** 递增。错误修复被定义为修复不正确行为的内部更改。
发布策略
k6 发布是一组更改，用于更新或向产品添加新功能，并在全球范围内以独特且新的可识别版本提供。
k6 遵循并与Grafana Labs 发布阶段 对齐。并非所有更改都严格或顺序地遵循发布阶段的每个步骤。大多数更改直接从实验阶段转为通用版本 (GA)。
发布频率
新 k6 版本的发布计划如下
| 版本 | 周期 |
|---|---|
| 主版本 | 每年一次 |
| 次版本 | 每六周 |
| 补丁版本 | 根据优先级，按需发布 |
与 Grafana 生态系统中观察到的实践一致，这使我们能够保持固定的节奏，为更好的功能规划、发布沟通和可见性提供机会，同时定期清理已弃用的功能，帮助随着时间推移减少技术债务。
我们稳定且受支持的 API 面是什么？
在定义 k6 的稳定 API 面时，我们旨在提供清晰稳定的接口，保证根据我们的版本控制策略进行维护和支持。我们稳定且受支持的 API 面包括几个关键组件，每个组件对于我们的用户及其集成工作流程都至关重要。
对以下描述的任何 API 的更改都将被视为破坏性更改。请注意，以下列表意在作为允许列表，任何未明确提及的 API、库或组件均被视为排除在外。例如，k6 REST API 是一个可访问但不受支持的 API 面覆盖的示例。
选项和命令行界面
我们稳定且受支持的 API 面包括 k6 选项集，这些选项集通过 k6 支持的各种配置方法（如选项对象、配置文件、环境变量等）向用户公开。
k6 命令行界面 (CLI)，包括命令、子命令和标志，也是稳定且受支持的 API 的一部分。这些命令对于在本地和云端启动和管理测试执行至关重要。
JavaScript 解释器
k6 脚本使用 JavaScript 编写，其执行环境支持特定的 JavaScript 语法和 ECMAScript 特性，因此 k6 JavaScript 解释器被视为 k6 稳定且受支持的 API 面的一部分。
这确保用户可以在 k6 主版本的生命周期内编写和执行具有可预测行为和兼容性的脚本。
模块
k6 直接暴露给脚本的*核心*模块，例如 k6, k6/http, k6/execution，是 k6 体验以及 k6 与其用户之间接口的另一个关键方面。因此，它们是稳定且受支持的 API 面的一部分。这包括模块中公开暴露和文档化的任何类、属性、方法、函数或相关签名。
核心模块的完整列表可在JavaScript API 页面上找到。
实验性模块，可通过其 k6/experimental 前缀的导入路径识别，明确排除在稳定且受支持的 API 面之外。
扩展
我们稳定且受支持的 API 面还包括扩展 API，它使内部和外部开发者能够构建自定义模块和输出，作为 k6 代码库的一部分或作为外部扩展。
它涵盖了 go.k6.io/k6 中公开可用的任何包。因此，go.k6.io/k6/internal 包下的所有包都被排除在外。
这包括 go.k6.io/k6/js/modules Go 包，内部和外部开发者可以用来构建模块扩展，以及 go.k6.io/k6/output，可用于构建 k6 的自定义输出。
它还包括公开给开发者以促进这些扩展开发的公共 k6 Go 包。例如，当前 go.k6.io/k6/lib 包，其中放置了 go.k6.io/k6/lib.State 类型。
输出
我们保证指标、日志、跟踪和画像输出的稳定性和支持，这些输出在端到端流程中由我们完全控制。这包括 JSON、CSV、云指标、日志和跟踪输出，以及 OpenTelemetry 格式，同时排除依赖第三方平台和协议的输出。
指标
我们保证指标名称、类型和单位的稳定性。对这些内容的任何更改都被视为破坏性更改，并将根据我们的版本控制策略进行处理。这样做确保任何基于 k6 构建的产品或制品（如仪表盘）能够保持可靠和一致的体验。
弃用、破坏性更改和迁移政策
破坏性更改
在不断发展的产品中，破坏性更改有时是不可避免的。它们要求 k6 用户积极应对，因为更改后的状态与之前状态不向后兼容。
因为我们遵循SemVer 2.0.0 版本控制规范，我们的工作假设是破坏性更改总是会导致新的主版本。当 k6 团队决定引入破坏性更改时，这将自动确定需要一个新的主版本。
当 k6 发布新的主版本时，我们应该明确说明，清晰地沟通破坏性更改，并提供用户迁移的说明。
破坏性更改有两种类型
- 移除
- 更新
当添加破坏性更改时，k6 团队将遵循以下步骤
移除 API 或功能
- 根据专门的政策弃用当前的 API 或功能。
- 如有必要，添加替代解决方案。理想情况下，这应是当前维护状态下的小版本中的实验性版本。或者，它可能在预览版本中提供。
- 提供迁移路径的文档。
- 继续移除 API 并发布新的主版本。
更新 API 或功能
- 应用更改，然后在下一个主版本中发布。如果更改显著，可能方便在预览版本中提供，以支持迁移路径，直到该版本全球可用。
- 提供迁移路径的文档。
弃用
当 k6 团队打算移除 API 或功能时，会将其标记为*已弃用*。这发生在 API 过时、被另一个 API 取代，或因业务或技术原因而停止使用时。已弃用的 API 在其弃用阶段仍然可用，并且我们保证它们将在当前主版本的整个生命周期内得到维护。
弃用将通过多个沟通渠道宣布，然后才会正式实施
- 发布说明。
- 官方文档。
- 当用户直接与该功能交互时。
- 建议使用已有的替代方案，但这不应视为强制要求。
迁移
当引入破坏性更改或 API 被取代时，将向用户提供迁移指南文档，以帮助他们理解如何从一个版本迁移到另一个版本。迁移路径将在官方文档中提供，并在所有其他沟通渠道中提及。
支持和开发政策
我们根据 k6 版本可以实现的四种状态定义 k6 支持和开发政策。在任何给定时间，我们都有
- **正在开发中** 的版本是 k6 即将发布的下一个版本。请注意，此版本可能启动一个新的主版本（例如，在最新版本为 v2.8.2 时开发 v3.0.0），也可能是对最新版本的新的次要或补丁迭代。
- **积极维护中** 的版本是 k6 最新发布的主版本。
- **受支持** 的版本是上一主版本中最新发布的 k6 版本。
- **已弃用** 的版本是之前发布的一系列 k6 版本。
因此，在开发和支持工作流程中，k6 开源项目积极开发 k6 的下一个版本，维护最新的主版本，支持上一主版本，并且不为早于受支持版本的任何版本提供任何支持。
任何既不在开发、维护或支持中的旧版 k6 都被视为**已弃用**，并且不会再接收进一步的更新或开发，包括错误修复或安全更新。用户可以自行承担风险使用这些版本。
指导方针
- *功能不会从一个主版本回移植到任何之前的版本*。
- 仅为每个支持类别的最新版本提供更改：*在任何给定时间点，只有一个官方的开发中版本和积极维护中版本*。我们不支持每个支持路径的多个版本。例如，假设在 v1.1.0 中发现了一个错误，而最新发布的 v1.Y.Z 版本是 v1.3.2。在这种情况下，当且仅当最新版本受到影响，并且错误或安全问题被认为足够重要时，开发团队才会优先发布一个修复，该修复将在 v1.3.3 版本中发布。用户不能期望发布 v1.1.1 的修复版本。
- 其他基于 k6 构建的 Grafana 产品、服务和团队应基于我们的支持政策开发其版本集成。
错误和安全问题
错误和安全问题种类繁多，影响各不相同。有些问题很关键，会损害用户安全或影响软件功能，而另一些则是无需立即处理的小麻烦。
k6 开源核心团队负责评估这些问题的严重性，并听取受影响利益相关者的意见。
我们根据错误对用户或产品功能的影响对其严重性进行分类。高严重性错误会导致部分用户无法正常或完全使用软件。根据严重性，团队要么立即发布补丁，对于不太关键的错误，则会将修复推迟到下一个计划发布。
安全问题在可用时使用 CVSS（通用漏洞评分系统）评分进行分类。在没有 CVSS 评分的情况下，我们与安全团队和受影响团队协作评估威胁。此评估考虑了对客户、用户、系统健康和数据完整性的潜在威胁。与错误修复类似，应对措施要么是针对高严重性问题的即时补丁发布，要么是针对低严重性问题的延迟修复。
保证
开发中
在 k6 开发生命周期的任何时候，下一个 k6 版本都在开发中。
k6 的下一个版本可以是主版本、次版本或补丁版本。此开发中的版本随后将根据我们的版本控制策略和规范发布，并成为 k6 的最新维护版本。
积极维护中
在当前活动的主版本下发布的最新版本被维护。
如果发生错误、安全问题或必要的依赖更新
- 如果开发中的版本预计仍在同一个主要版本范围内，则修复或更新预计会落地在该版本中，一旦发布，该版本将依次成为下一个维护版本。
- 如果开发中的版本预计将切换到新的主要版本范围，则修复或更新将包含在当前维护的主要版本范围内，并作为最新的维护版本（补丁）发布。
支持的 k6 版本
在任何时候，之前的主要版本都将处于支持模式。受支持的 k6 版本将不会收到进一步的更新或功能回溯，但会继续接收主要和安全漏洞修复。它的次要版本预计不会再发生变化，并且应该只看到其补丁版本增加。
已弃用的 k6 版本
一个 k6 的主要版本，如果与最新版本相隔两个主要版本（例如，当最新版本是 v3.0.0 时，v1.0.0），则被视为已弃用，并且不再接收任何形式的支持。次要版本也适用同样的原则。
实际场景
在最新发布的 k6 中发现了一个主要（bug 或安全）问题
最新发布的 k6 正在积极维护。在此版本的主要范围内，只有一个维护版本，即最新版本。
因此，当安全问题或 bug 影响到积极维护的版本时，k6 团队会制定一个修复方案，并发布当前维护版本的新补丁版本。尽管开发中的版本应该集成这些更改，但我们仍保留发布新的中间版本的权利。
如果该问题或 bug 也影响到受支持的 k6 版本，我们会对其应用修复，并发布当前受支持的 k6 版本的一个补丁版本。
如果该问题也影响到已弃用的 k6 版本，我们将不采取任何行动，并建议用户升级到至少最新的受支持版本的 k6。
在受支持的 k6 版本中发现了一个问题
当在当前受支持的 k6 版本中发现安全问题或 bug 时，k6 团队会在支持版本的特定分支中创建修复方案。然后发布受支持版本的新补丁版本，该版本将成为新的受支持的 k6 版本。
如果该问题也影响到当前为主要版本的 k6 版本，则应在维护版本的主要范围内发布一个单独的修复作为补丁版本。
如果该问题也影响到已弃用的 k6 版本，我们将不采取任何行动，并建议用户升级到至少最新的受支持版本的 k6。
在已弃用的 k6 版本中发现了一个问题
如果在已弃用的版本中发现问题（安全相关或 bug），我们将不采取任何行动，并建议用户升级到受支持的 k6 版本。
实验性功能
在 k6 中，有些 API、功能和模块被明确标记为实验性。
这些 API、功能和模块是由我们认为对用户和 k6 的发展有价值的更改或新能力组成。但它们尚未稳定。
实验性 API、功能或模块可能会在没有事先通知的情况下发生破坏性更改并被完全移除。我们的支持政策不涵盖实验性 API、功能和模块。因此，我们建议产品、项目和团队不要在关键任务操作中明确依赖它们，如果可能，应基于它们进行构建。
它们应该在内部和最重要的外部进行标记和沟通。当用户与实验性功能或模块交互时，必须明确告知他们。如何做到取决于引入更改的层级，并且可能因具体情况而异。
例如，一个 JavaScript 模块应该通过其导入路径（包含 k6/experimental/ 前缀）来识别其实验性状态。官方文档中也强烈鼓励宣传实验性状态。然而，仅将其作为唯一层级不应被视为充分的沟通。开发团队负责根据具体情况决定合理的沟通层级。
实验性 API、功能和模块最终可能会变得稳定。当这种情况发生时，在大多数情况下会导致一个新的 k6 次要版本。实验性模块的导入路径将变为已弃用，并将在未来的几个次要版本中移除，同时会发出通知。
版本控制政策
我们保留作为主要版本发布的一部分修改版本控制策略和政策的权利，前提是符合以下约束：
- 我们维护文档本身修改的变更日志。
- 文档保持公开并可供用户访问。
- 我们在新版本发布的背景下沟通变更。
例如，假设我们决定引入新的受支持的 API 表面，如 REST API v2。我们将相应地修订本文档，并在下一个主要版本发布时发布并强制执行对受影响工作流程的更改。
