译自 halo2 book：dev/features.md

特性开发(Feature development)

有时特性开发(feature development)需要随时间不断迭代某个设计。尽早在下游(downstream) crate 中开始使用某个特性，对积累 API 与功能上的使用经验很有帮助，而这些经验又能在特性稳定化之前反馈到它的设计中。为实现这一点，我们采用一种受 Rust 编译器启发（但并不完全相同）的三阶段 nightly -> beta -> stable 开发模式。

特性标志(Feature flags)

每个尚未稳定化的特性都有一个默认关闭的特性标志(feature flag)来启用它，形式为 unstable-*。当该特性标志被禁用时，各 crate 的稳定 API(stable API)绝不能受到影响，除非是某些会按具体情况逐一考量的复杂特性。

我们还提供了两个元标志(meta-flag)，用于启用某个稳定化级别的全部特性：

• beta 启用所有处于 "beta" 阶段的特性（并隐式启用所有处于 "stable" 阶段的特性）。
• nightly 启用所有处于 "beta" 和 "nightly" 阶段的特性（并隐式启用所有处于 "stable" 阶段的特性），即启用全部特性。
• 当两个标志都未启用（且没有任何特性专属标志被启用）时，实际上只启用处于 "stable" 阶段的特性。

特性工作流(Feature workflow)

• 如果维护者们达成了大致共识(rough consensus)，认为某个实验性特性总体上是受欢迎的，那么可以乐观地以较低的审查标准，把它的初始实现合并进代码库，并置于一个该特性专属的特性标志之后。该特性的标志会被加入 nightly 特性标志集合。
  • 在 halo2 各 crate 的下一次常规发布(general release)中，该特性即可被下游已发布的 crate 使用。
  • 该特性后续的开发与完善可以通过额外的 PR 就地(in-situ)进行，并配以额外的审查。
  • 如果该特性最终与其他特性（尤其是已稳定化的特性）产生不良交互，那么之后可以将其移除，而不影响 stable 或 beta 的 API。
• 一旦该特性经过了充分审查，并且达到了某个 halo2 用户认为其已可用于生产(production-ready)（且愿意或计划将其部署到生产环境）的程度，该特性的特性标志就会被移入 beta 特性标志集合。
• 一旦该特性经过了等同于 stable 审查策略的审查，并且达成了大致共识，认为该特性对更广泛的 halo2 用户群体有用，该特性的特性标志就会被移除，该特性也随之成为主维护代码库的一部分。

对于更复杂的特性，上述工作流可能会辅以 beta 和 nightly 分支；这一点将在某个需要此机制的特性被提名为纳入候选时再行确定。

进行中的特性(In-progress features)