(乍一看以为懂了,再看似懂非懂,细看完全不懂,太难了,语言是个坎)
Vue RFCs
一、RFC是啥?
"RFC"(request for comments) 请求评议,目的是为新功能进入框架提供一致且受控的路径。很多变化,包括bug修复和文档说明的更进可以在日常的GayHub工作流中实施和评估。但是有些实质性的变化,我们要求这些变化经历一个设计过程,并且在Vue核心团队和社区中一致通过。
二、RFC生命周期
一个RFC会经历以下阶段:
Pending:这个RFC被作为一个PR(pull request)被提交。
Active:这个RFC被合并并且正在实施。
Landed:这个RFC提出的更改在实际版本中被发布。
Rejected:这个RFC的PR没被否决。
三、什么时候遵循这个过程
如果你的改变涉及如下项目模块,你就需要走这个流程
- Vue core
- Vue Router
- Vuex
- Vue CLI
我们限制这些仓库的RFC流程,以便以一种更易于管理的方式来检验这个流程,同时也想在将来将其扩展到vue组织下的更多项目中。目前,如果你希望对其他项目提一些修改建议,请用他们的对应的issue列表。
构成一个“实质性”变化的定义是基于社区规范的演变,可能包含以下几点:
- 创建了一个新API的新特性
- 改变了现存的一个API的定义或行为
- 删除一个已经发布的功能的其中的特性
- 关于新的习惯用法或约定的介绍,即使他们不包含对Vue本身代码的修改
有些不需要RFC的改变:
- 添加提高目标、数量的质量标准(例如提速、对浏览器更好的支持)
- 修正客观存在的不正确的表现
- 重新措辞、重组或重构
- 添加或移除警告
- 添加的内容只被Vue的实现者注意到,对用户不可见
如果你未通过RFC流程提交了一个新特性的合并请求,它可能会被关闭,并且要求先走RFC流程。
四、为何要这样做
首先非常感谢您愿意为Vue贡献一份力而考虑一些新的特性或改变。同时,随着Vue被越来越广泛的使用,我们需要更谨慎并且更仔细地斟酌每个改变的可能会对前端用户产生的影响。换句话说,我们认为Vue已经到了一个需要有意识的防止新的API带来的长远的复杂性问题的阶段。
这些约束条件和权衡方案可能不会立刻要求那些打算提交他们在使用中遇到的一个明显问题的改变的用户。RFC过程旨在引导你在想要改变Vue中问题时站在我们的角度思考,如此我们能够在讨论为何采纳或者不采纳这个改变时达成共识。
五、在提交时收集反馈
一个RFC流程有助于在深入API详细设计层面之前收集对你观点的反馈。你提出的issue可能会在这个仓库里展开一个深入讨论,最终会形成一个带有实现设计的系统阐述方案的合并请求。
六、实现过程