Skip to content

Commit

Permalink
Doc: 完善了文档结构
Browse files Browse the repository at this point in the history
  • Loading branch information
E0SelmY4V committed Apr 4, 2024
1 parent c6af387 commit 169bf56
Show file tree
Hide file tree
Showing 2 changed files with 48 additions and 1 deletion.
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,6 @@ Funny TS utility types 〜 激动人心的工具类型
本项目是[「精确类型」](https://github.com/accurtype/accurtype)配套开发流程控制管理工具。
通过本工具,您可以实现以*功能*为基本开发单位的开发。

[阅读包的说明文件](./packages/accureleaser/README.md)
[阅读包的说明文件](./packages/accureleaser/docs/)

<!-- 详细说明可以参考[文档]()。 -->
47 changes: 47 additions & 0 deletions packages/accureleaser/docs/readme.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
# 简介

[「精确类型」代码仓库](https://github.com/accurtype/accurtype)是一个 TypeScript 类型工具库。

这个工具库使用一套独特的开发流程,可以概括性地称为**以功能为中心的迭代速度很快的开发流程**
我也不知道简称什么,就暂时简称功能快速开发吧。

`accureleaser` 就是功能快速开发的一个实现工具。

## 名字由来

「精确类型」的英文名是 Accurate Type,包名是 `accurtype`
可以发现包名就是把 Accurate 和 Type 两个单词拼一起。

所以「精确类型」配套开发流程管理工具的英文名是 Accurate Releaser,自然包名就是把两个单词拼到一起,变成 `accureleaser` 了。

## 为什么需要功能快速开发

功能快速开发其实一开始并不是一整套完全的开发流程。

由于「精确类型」是一个由高端社区驱动的项目,我就选择通过 GitHub Actions 来发布 npm 包。
因为这样子仓库的右边就有“Packages”栏,看起来更加高大上了。

然鹅在尝试给「精确类型」编写自动发布流程时,我发现自动发布作为一种不能人工介入的发布方式,是需要通过特定的时机才能发布的。
时机的选择就比较耐人寻味:究竟是每天、每周这样的定时发布,还是每有一个版本就发布一次?
考虑到版本标签还可能有测试版、抢鲜版和正式版的区别,版本号还有破坏性 API 、功能增加和问题修复的区别,版本发布的时机就需要根据开发流程来决定。
然而如果没有一个合适的管理工具,开发流程是十分自由的,根本没法保证版本发布时机的准确性。

我于是就搜索有哪些开发流程管理工具,发现了一个叫 [semantic-release](https://github.com/semantic-release/semantic-release) 的工具。
(所以想要知道为什么需要功能快速开发,可以先去了解 [semantic-release](https://github.com/semantic-release/semantic-release?tab=readme-ov-file#-semantic-release) 。)

相较于 semantic 提供的比较主流(大概)的开发流程,功能快速开发有以下区别:

- 考虑到「精确类型」的开发较为连贯,仅有破坏性更新会需要更正主版本号,架构更改问题很少。
所以功能快速开发并不强调不同代版本之间的互动,取而代之是通过合并相互依赖的开发分支来维护一代常用版本。
- 将“feature”这种提交变成了各个分支~也就是说并不是一次提交实现一个功能,而是一个开发分支实现一个功能。

这种开发方法适用于工具包这种功能之间差异较大,且单个功能开发时间较长的开发环境。
- 由于「精确类型」是一个类型库,对类型的修改就是对库 API 的修改——任何类型工具被修改,都相当于 API 直接被修改,也就是一个破坏性更新——所以一个功能的发布要非常慎重。

为此,功能快速开发对每个功能都引入了三个开发阶段(milestone):`alpha``beta``release`,而且引入了分支之间的依赖关系用以判断一个功能是否能够被合并到稳定版本中。
- 但是功能开发周期过长会导致用户无法及时用到具有最新功能的版本,所以功能快速开发引入了前瞻版本这个概念,来代替 semantic 开发流程中的“下一代”版本扮演 next 版本的角色。

前瞻版本不用来开发,仅仅是一个比正式版本功能添加得更早的专门用来使用的版本。

如果你阅读以上内容,充分了解了功能快速开发的特点,你就能自己判断为什么需要这种开发流程了。
如果你阅读以上内容也没充分了解,欢迎[反馈文档问题](https://github.com/accurtype/releaser/issues)或者为这个文档贡献!

0 comments on commit 169bf56

Please sign in to comment.