添加新功能

新特性始于 RFC（征求意见稿）。RFC 流程是社区成员和核心团队成员提出变更（例如添加新特性或弃用功能）的方式。

有关 RFC 流程的更多信息，包括查看现有 RFC 的状态、学习如何撰写自己的 RFC、对提议的 RFC 提供反馈以及如何帮助将已接受的 RFC 全面落地，请访问 RFC 网站。

以下是在 ember.js 仓库中工作的一些建议。

要了解如何提交拉取请求（Pull Request），请查阅 CONTRIBUTING.md 说明。

通常，新特性开发应在 main 分支上进行。

Bug 修复不应引入新 API 或破坏现有 API，且不需要特性标志（feature flags）。

新特性可以引入新 API，但需要使用特性标志。它们不应被应用到发布分支或测试（beta）分支，因为根据语义化版本规范（SemVer），引入新特性需要升级小版本号。

安全修复不应引入新 API，但如有必要，在严格受控的情况下可以破坏现有 API。此类破坏应尽可能降到最低。

紧急 Bug 修复是指需要应用到现有发布分支的修复。如果可能，它们应该在 main 分支上进行，并加上 [BUGFIX release] 前缀。

Beta Bug 修复是指需要应用到测试分支的修复。如果可能，它们应该在 main 分支上进行，并标记为 [BUGFIX beta]。

安全修复需要应用到测试分支、当前发布分支以及上一个标签版本。如果可能，它们应该在 main 分支上进行，并标记为 [SECURITY]。

特性必须始终使用特性标志进行封装。该特性的测试也必须使用特性标志进行封装。

因为构建工具会处理特性标志，所以标志必须使用严格的这种格式。我们选择条件语句而不是块形式，因为函数会改变周围的作用域，可能会导致提前返回的问题。

import { FEATURES } from '@ember/canary-features';

if (FEATURES.isEnabled("feature")) {
  // implementation
}

测试将始终在开启所有特性的情况下运行，因此请确保该特性的所有测试都能通过当前特性的状态。

与特定特性相关的提交应包含类似 [FEATURE htmlbars] 的前缀。这将使我们能够在未来快速识别特定特性的所有提交。特性永远不会被应用到测试或发布分支。一旦一个测试或发布分支被创建（cut），它就包含了它未来所拥有的所有新特性。

如果一个特性已经进入测试或发布阶段，并且你在 main 分支上提交了一个修复该特性中 Bug 的代码，请将其视为上述描述的 Bug 修复进行处理。

Canary 版本（基于 main 分支）将包含所有特性，并由原始源代码中的条件语句进行保护。这意味着 Canary 版本的用户可以在创建应用之前启用他们想要的任何特性。

module.exports = function(environment) {
  let ENV = {
    EmberENV: {
      FEATURES: {
        htmlbars: true
      }
    },
  }
}

仓库根目录将包含一个 features.json 文件，其中列出了应在测试或发布构建中启用的特性列表。

此文件在创建分支时进行填充，且在原始分支之后可能不会获得额外特性。但它可能会移除特性。

{
  "htmlbars": true
}

构建过程将移除列表中未包含的所有特性，并移除列表中所含特性的条件语句。

对于一个新的 PR：

1. 测试将在开启所有特性标志的情况下对 main 分支运行。
2. 如果一个提交被标记为 [BUGFIX beta]，该提交将被 cherry-pick 到测试分支，并对该分支执行自动化测试。如果提交未能干净地应用或测试失败，构建将失败。
3. 如果一个提交被标记为 [BUGFIX release]，该提交将被 cherry-pick 到发布分支，并对该分支执行自动化测试。如果提交未能干净地应用或测试失败，构建将失败。

对于提交到 main 的新代码：

1. 测试将如上所述执行。
2. 如果构建通过，提交将被 cherry-pick 到适当的分支。

其思想是，新提交应作为 PR 提交，以确保它们在 PR 合并时能够干净地应用。

每六周，核心团队会执行以下流程。

测试分支上所有剩余的特性都会经过就绪状态的审查。如果某个特性尚未就绪，它将从 features.json 中移除。

完成后，测试分支会被标记并合并到发布分支。

main 分支上的所有特性都会经过就绪状态的审查。为了让一个特性在此阶段被视为“就绪”，它必须在当前状态下已准备好且没有任何阻塞问题。即使某些特性已经很接近完成，如果还需要在测试分支上进行额外工作才能使其就绪，它们也会被拒绝。

由于该流程每六周进行一次，特性很快会有下一次进入的机会。

完成后，main 分支将合并到测试分支。随后会添加一个包含已就绪特性的 features.json 文件。

每周，我们都会为测试分支上保留的特性重复进行准入/拒绝流程。任何变得不再就绪的特性都将从 features.json 中移除。

完成后，测试版发布会被标记并推送。