strint

• Feature development process
  • 以 Feature 为粒度做开发
  • Feature Stage
    • 功能成熟度分级及其标准
    • Feature Stage Review
    • 关于里面的标准看起来要求多
  • Feature Relase Process / Cycle
    • Python release cycle
    • django release process
    • PyTorch Release
  • 进一步阅读的参考资料

Feature development process

本文想了解何把 Feature 推向成熟，开源领域对此有成熟的经验可以参考。

讨论3个子问题， 为什么以 Feature 为粒度来推动软件开发；Feature 成熟如何判定； Feature 开发流程是怎样的。

以 Feature 为粒度做开发

软件由功能集合组成，功能集合里面由单个Feature组成。基于Feature开发，可以把大的任务细分成可执行的功能。

Feature Stage

软件一般以 Feature Stage 来评估功能成熟度，常见的 Stage有：Pre-alph、Alpha、Beta、RC、Stable. 后面详细介绍其标准。

功能成熟度分级及其标准

• Stable Stage
  • 目的：发布以提供稳定版本，支持广泛的用户做长周期使用；
  • 受众：所有用户；
  • 稳定性：必须在长周期(比如1年)、主版本内（比如1.0内）能被稳定使用；
  • 功能完备性：和RC一样；
  • 测试：和RC一样；
  • 性能：和RC一样；
  • API：和RC一样，API如有特别必要的破坏性改变，应考虑新增功能模块，或在下个新的主版本中进行；
  • 文档：和RC一样；
• RC (Release Candidate) Stage
  • 目的：发布以供稳定、完备的版本，可在生产环境做部署和评估；
  • 受众：所有用户，包括想部署生产环境部署的用户；
  • 稳定性：默认可以开启，可广泛地在用户中推广使用，通过测试后可在生产环境中广泛部署，后续发现的新问题会被公开披露和修复；
  • 功能完备性：完善异常处理，除了处理正常输入、对异常情况也能良好处理；
  • API：API进行外部用户评估，API定型, 保证长周期(比如1年)、大版本内（比如1.0内）的稳定性、兼容性，并进行长期功能维护；
  • 性能：提供量化的评估报告和文档，保证后续的升级不导致性能衰退，在外部环境对性能评估、对扩展性做评估；
  • 测试：修复和测试通过Beta Stage后发现的新问题，在外部环境做过端到端的部署验证，且体验良好；
  • 文档：功能被加入核心功能集的说明文档中，体现在功能集中的作用；
• Beta Stage
  • 目的：发布以提供较稳定、完备的可用版本；
  • 受众：所有用户，尤其是愿意提供功能反馈的用户，对功能有需求且不介意未知边界用例报错的用户，在开发环境、测试环境中使用，在生产环境中做评估性的少量部署；
  • 稳定性：默认可以开启，因为是新功能所以还可能有小的bug，但后续发现的新问题会被公开披露和修复；
  • 功能完备性：做功能完备性设计，完善功能，覆盖对该功能的各种场景的需求，可以长周期不用升级代码，就能解决对该功能的大部分需求；
  • API：做良好的API设计，经过完全的API Review，被认定是完备和稳定的，得到种子用户的认可，API不会被轻易废弃，但细节仍有可能做调整；
  • 性能：对性能评估，对扩展性做评估；
  • 测试：测试完备，覆盖常规用例和边界用例，且做多种端到端的集成测试；
  • 文档：提供完备的使用范例、教程、术语说明等；
• Alpah Stage
  • 目的：发布以供体验实验性功能，以获取早期反馈；
  • 受众：开发者，愿意提供反馈的专家用户，在开发环境、测试环境中使用；
  • 稳定性：活跃的开发中，默认不开启，使用中可能会出现bug；
  • 功能完备性：核心功能完成开发，但非典型的功能、非典型的使用场景可能没有支持；
  • API：有功能定义明确的API，但是还没严格的API Review，可能会做API变更，可能会被移除；
  • 性能：设计上需要做性能要求，且被评估；
  • 测试：对该功能的核心需求完成单元测试，且测试需要稳定通过，在该需求的典型场景做了验证，可能有corner case bug，在非典型场景可能有未知bug；
  • 文档：提供API文档，介绍功能定义、开启方法、限制，最好附加关联的Issue和设计文档；
• Pre-alpha Stage
  • 目的：发布以供原型功能的验证或开发；
  • 受众：功能开发紧密相关的人员，在开发环境、测试环境中使用，不要在生产环境使用；
  • 稳定性：默认不开启，使用中可能会出现较多bug；
  • 功能完备性：有限的原型功能；
  • API：容易变化，可能会被移除；
  • 性能：未知，可能对总体性能有影响；
  • 测试：有限功能的测试，要求此阶段的代码不能影响其它已发布的功能；
  • 文档：可能没文档；

注：该定义主要参考了Google, IBM, Lyft推动的 istio 项目的 Feature stages，https://istio.io/latest/docs/releases/feature-stages/ ，感谢。

Feature Stage Review

升级Feature Stage，需要做严格的Review，以保证质量。这是 Code Review 之上的一层 Review.

关于里面的标准看起来要求多

仔细看会发现一个少不了，核心 Feature 走向 Stable，是整个软件走向 Stable 的必要条件。要做的事情没做，就达不到那个 Stage；达不到那个 Stage，就获得不了那个 Stage 的用户。比如一个 feature 是 alpha的，就只有内部用户、专家用户才用得了，这就限制了该功能的用户是个位数的。

参考资料：

• Google API Stability levels
• Google API Design Review
• Google life cycle of release
• litio feature stages
• k8s feature versions
• Oracle state of API
• django release process
• Software release life cycle
• Feature stages
• Software release process
• PyTorch Beta and Stable Release Example
• PyTorch “beta feature”
• PyTorch “is beta”

Feature Relase Process / Cycle

下面对几家流行软件的 Release Process做下调研。

Python release cycle

• 发布周期：17个月；下面以Python 3.9 的开发周期为例进行说明
• 前5个月，无版本开发周期
  • 3.9 development begins: Tuesday, 2019-06-04
• 中间7个月，alpha feature 开发周期，每月发布1个 alpha 版本，发布 alpha stage feature，版本号为3.9.0-alpha.x
  • 3.9.0 alpha 1: Monday, 2019-10-14
  • 3.9.0 alpha 2: Monday, 2019-11-18
  • 3.9.0 alpha 3: Monday, 2019-12-16
  • 3.9.0 alpha 4: Monday, 2020-01-13
  • 3.9.0 alpha 5: Monday, 2020-02-17
  • 3.9.0 alpha 6: Monday, 2020-03-16
  • 3.9.0 alpha 7: Monday, 2020-04-13
• 3个月的的 beta feature 开发周期，每2周发布1个 beta 版本，进入 beta 开发周期后，不会再新增 alpha feature，只完善alpha 到 beta，版本号为3.9.0-beta.x
  • 3.9.0 beta 1: Monday, 2020-05-18 (No new features beyond this point.)
  • 3.9.0 beta 2: Monday, 2020-06-08
  • 3.9.0 beta 3: Monday, 2020-06-29
  • 3.9.0 beta 4: Monday, 2020-07-20
• 1个月的RC，每2周发一个 RC 版本，版本号为3.9.0-rc.x
  • 3.9.0 candidate 1: Monday, 2020-08-10
  • 3.9.0 candidate 2: Monday, 2020-09-14
• 1个月后发布 stable 版本，此时正式发布3.9的稳定版，版本号为3.9.0，并标记为 stable
  • 3.9.0 final: Monday, 2020-10-05
• 之后进入5年的维护期，分为2个时期
  • 先是18个月的 bug fix 周期，发布3.9.x版本，每两个月一个，一共9个，版本号为3.9.x，
  • 之后是42个月的安全维护期，只解决安全性问题，不再发版本而是提供源码修复，最低维护状态；

参考资料：

• https://peps.python.org/pep-0602/
• https://github.com/actions/python-versions/blob/main/versions-manifest.json

django release process

版本规划

• Versions are numbered in the form A.B or A.B.C.
• A.B is the feature release version number. 部分前向兼容；
• C is the patch release version number, which is incremented for bugfix and security releases. 一定前向兼容，只做修复；
• Before a new feature release, we’ll make alpha, beta, and release candidate releases. These are of the form A.B alpha/beta/rc N, which means the Nth alpha/beta/release candidate of version A.B.
• each release series has its own branch, called stable/A.B.x

开发流程

• A.B.alpha开发和发布
  • 所有的新feature需要在A.B.alpha截至时间完成alpha，否则不在A.B版本发布
• beta开发和发布
  • beta开始后，该分支不能再加入任何新feature，只做alpha的完善
• RC发布预览版
  • 搜集和修复问题
• Stable
  • 一般在RC发布两周后发布Stable
  • 也看bug修复的情况

发布流程

• 8个月一个发布周期。每个发布周期后，Release Manager 会发布下一个周期的 timeline。每个周期分四个阶段。前三个周期的时间大致均等，最后一个周期很长。
• Phase one: feature proposal to get roadmap.
  • The first phase of the release process will include figuring out what major features to include in the next version.
  • This should include a good deal of preliminary work on those features – working code trumps grand design.
  • Major features for an upcoming release will be added to the wiki roadmap page.
• Phase two: development to get alpha release.
  • The second part of the release schedule is the “heads-down” working period.
  • Using the roadmap produced at the end of phase one, we’ll all work very hard to get everything on it done.
  • At the end of phase two, any unfinished features will be postponed until the next release.
  • Phase two will culminate with an alpha release.
  • At this point, the stable/A.B.x branch will be forked from main.
• Phase three: bugfixes to get beta and rc.
  • The last part of a release cycle is spent fixing bugs – no new features will be accepted during this time.
  • In parallel to this phase, main can receive new features, to be released in the A.B+1 cycle.
  • We’ll try to release a beta release one month after the alpha and a release candidate one month after the beta.
  • The release candidate marks the string freeze, and it happens at least two weeks before the final release(stable).
  • After this point, new translatable strings must not be added.
  • During this phase, mergers will be more and more conservative with backports, to avoid introducing regressions.
  • After the release candidate, only release blockers and documentation fixes should be backported.
• Phase four: Bug-fix for stable releases.
  • After a feature release (e.g. A.B), the previous release will go into bugfix mode.
  • The branch for the previous feature release (e.g. stable/A.B-1.x) will include bugfixes.
  • Critical bugs fixed on main must also be fixed on the bugfix branch; this means that commits need to cleanly separate bug fixes from feature additions.
  • The developer who commits a fix to main will be responsible for also applying the fix to the current bugfix branch.

参考资料：

• https://docs.djangoproject.com/en/dev/internals/release-process/
• https://code.djangoproject.com/wiki/Version1.11Roadmap

PyTorch Release

• PyTorch has a 90-day release cycle (major releases)
  • https://github.com/pytorch/pytorch
  • 其它细节没有找到资料，估计是按Facebook内部的节奏工作
• 实施
  • Issue 分类 + 值班
  • PR 分类 + 值班
  • 修复CI + 值班
  • 在Facebook做internal Release
  • 秘诀是值班的任务小巧（1小时可完成的）

参考资料：

• http://blog.ezyang.com/2021/01/pytorch-open-source-process/

进一步阅读的参考资料

• 成功的 Git 分支模型，https://nvie.com/posts/a-successful-git-branching-model/ （一个 Git 分支的实践经验总结）