@wxfe/gotron

An enterprise-class UI design language and Vue-based implementation

Usage no npm install needed!

<script type="module">
  import wxfeGotron from 'https://cdn.skypack.dev/@wxfe/gotron';
</script>

README

分支管理及流程

master——固定分支；新建feature分支从master拉取

qa———发布beta版本分支；

online——发布正式版本分支；稳定运行后，合并该分支到master；

1、无需RFC流程的情况

  • 常规 Bug 修复
  • 不影响已发布版本的特性迭代
  • 添加或删除警告或提示信息
  • 模块内部架构调整或代码重构
  • 性能或兼容性提升

流程速记

  1. 从master拉取feature/<描述或功能>分支，如修复常规bug，则从master拉取hotfix/<描述>分支
  2. feature分支自测没有问题后，发起MR到qa分支，相关负责人合并MR，并发布beta版本
  3. beta版本经业务线使用无问题后，合并feature分支到online，并由相关负责人发布正式版本

2、需要走RFC流程的情况

  • 添加一个新的包
  • 修改 API，包括入参、输出内容、或删除
  • 改变既有惯用开发方式
  • 任何可能导致或会导致已发布版本不可用的变更

RFC流程速记

  1. clone 仓库，从master主干拉 feature/<提案名称或描述> 分支
  2. 复制 0000-template.md 到 proposals 文件夹并改名为 0000-<提案名称或描述>.md，按照实际情况填充文档
  3. 发起 MR (Pending 阶段)
  4. 发起必要讨论，并达成共识 (Active 阶段)
  5. 代码实现、测试、发布（参考无需RFC情况的流程）

Gotron RFC

一般情况下，大部分特性更新、Bug 修复等代码变更可以遵循普通的 Git Flow 流程，通过发起 Merge Request 和 Code Review 完成。但某些更新因为会导致 API 功能模块 甚至 系统架构 发生重大改变。对于这类更新，我们需要设计一个流程来保证开发团队与社区中能达成共识。

RFC （Request For Comments）就是一种为了保证重大特性更新和架构更改能够顺利推进的一种流程机制。

哪类更改需要 RFC 流程

如上所述，任何导致 API 、功能模块、系统架构发生改变或导致代码整体结构更改时都需要 RFC 流程，例如：

  • 添加一个新的包
  • 修改 API，包括入参、输出内容、或删除
  • 改变既有惯用开发方式
  • 任何可能导致或会导致已发布版本不可用的变更

以下类型的改动不需要进行 RFC 流程：

  • 常规 Bug 修复
  • 不影响已发布版本的特性迭代
  • 添加或删除警告或提示信息
  • 模块内部架构调整或代码重构
  • 性能或兼容性提升

为什么需要 RFC 流程？

繁琐的流程对迭代与开发效率来说是有害的。但出于以下的一些考量，我们愿意降低开发效率引入 RFC 流程：

  1. 稳定性

    现有 RFC 流程能让我们尽可能降低每次迭代对老用户的影响，同时会一定程度和版本发布挂钩，保证迭代尽可能符合语义化版本号规范

  2. 开放公开

    我们希望我们的迭代尽可能地开放、公开、透明。每一个人都可以参与 RFC 的讨论与开发，用自己的行动影响下一个版本的 Gotron(体系)。
    同时我们也希望借此提升社区的参与度，让更多人参与到 Gotron 的建设

  3. 质量

    RFC 流程要求实现之前有设计文档并接受社区的评审与讨论，这对于具体的代码实现有非常大的帮助

  4. 追踪

    我们希望每一个 RFC 文档及关联的 PR 都能反应对于新增、取消或修改某一特性背后的思考（或妥协）。这对于体系整体长期的发展和想要深入了解 Gotron 的开发者来说非常重要

RFC 流程机制

如果需要 RFC 提案的改动在未来的 Gotron(或体系相关模块) 版本中发布，需要先让 RFC 提案文档在 RFC 仓库中被合并

RFC 发起流程:

  • Clone RFC 仓库:
    git clone ssh://git@stash.weimob.com:7999/yazuo-membership/new-weimob-ui-components.git
cd new-weimob-ui-components
  • 创建提案分支，分支名应按照 feature/my-feature 命名(my-feature 为能够描述该 RFC 的短语)
  • 复制 0000-template.md 到 proposals/0000-my-feature.md (my-feature 与分支名中的 my-feature 一致，0000 是 RFC 的序号，先不用更改)
  • 根据 proposals/0000-my-feature.md 填充 RFC 提案，描述清晰的动机与原因、展示具体的案例和设计的细节、以及可能造成的问题。RFC 提案进入 Pending 阶段
  • 向 RFC 仓库发起 Merge Request。在这个阶段开发团队与社区一同讨论 RFC 提案
  • RFC 提案在社区中达成共识，RFC 提案进入 Active 阶段
  • RFC 提案的代码实现在相关仓库被合并，RFC 提案进入 Landed 阶段，RFC 提案也会被合并进入 RFC 仓库
  • 相关模块的负责人将会决定 RFC 提案的变更在哪个版本开始发布

在 Pending 阶段的 RFC 提案

当一个 RFC 提案作为 Merge Request 请求合并时：

  • 提案会被团队和社区一同讨论，最终得出的细节和结论不一定会和 RFC 的最初提案一致
  • 提案可能会由于没有达成共识而被拒绝，相关业务的负责人需要给出拒绝的原因
  • 提案在达成共识之后会进入 Active 阶段，开发团队或社区可以开始着手提案的代码实现
  • 提案可能因为无人讨论因此无法达成共识，开发团队可以根据实际情况是否接受提案

在 Active 阶段的 RFC 提案

当一个 RFC 提案在社区中达成共识，进入 Active 阶段之后，也并不意味着 RFC 提案的更改就是板上钉钉的事情。RFC 提案的代码实现不一定可以合入相关业务的代码的主仓库。但 RFC 提案进入了 Active 的确意味着开发团队和社区认可 RFC 提案的更改，并认为这是将来应该去实现的一件事。

也就是说，当 RFC 提案进入 Active 阶段时并不认为这个改动被分配了优先级，具体的版本发布时间也需要在代码实现之后才能确定。

RFC 提案的实现

原则上 RFC 提案文档作者并没有义务对 RFC 提案进行代码实现。但我们非常欢迎 RFC 提案的作者或任何一位开发者如果有愿意在 RFC 提案文档被接受后去进行代码实现。

已经被接受的 RFC 提案需要包含一个在 Gotron 相关仓库(主仓库或其他体系内仓库)的 Merge Request 链接（即便 MR 还在起草或未完成阶段），RFC 提案的作者和 Gotron 团队需要去督促 RFC 实现 MR ，并朝着 RFC 提案文档所描述的方向去推进。

Gotron RFC 流程机制受到了来自 Rust RFC Process、React RFC Process 和 Vue RFC Process 的启发。