仓库多分支策略

[wssgcg1213]

Kraken 对 Flutter 的版本有要求, Flutter 的版本更新相对比较频繁，而同一个 Kraken 版本无法同时支持多个 Flutter 版本 (含 Break Change)，所以我们需要有一个多分支的管理模型来支持同时对多个 Flutter 版本的支持进行维护

以下分支策略仅针对 openkraken/kraken 仓库

主要分支

长期存在 1 个分支, 设定为保护分支

• main

main 分支的 HEAD 游标指向 Kraken 已发布最新版本的 tag 位置。

版本分支

可同时存在多个版本分支，辅助并行开发，格式如下

• release/flutter-2.2.x/0.8.x
• release/flutter-2.2.x/0.9.x
• release/flutter-2.5.x/0.9.x

对发布分支设定分支保护，不允许删除。

发布时通过版本分支进行发布，但是不删除版本分支，通过 tag 标记发布时的 head 位置

版本号如 0.8.0+1 表示 Kraken@0.8.0 支持 Flutter 2.0.x 的第一个版本

发布后，如果该分支是 Kraken 已发布的最新版本，则 rebase main 分支到此位置

协助分支

泛指 feature/fix/docs 等单项功能的分支

• feature/foo
• fix/bar
• docs/some-thing
• ...

协助分支一律从 release 分支检出，然后发起合并到 release 分支。

协助合并后需要删除。同 Kraken 版本号的 release 分支之间可以通过 cherry-pick 进行代码同步。

[cnryb]

• release/flutter-2.2.x/0.9.x
• release/flutter-2.5.x/0.9.x

用户如何知道所使用的 kraken，支持的是哪个 flutter 版本？普通的用户不一定会关注源代码

同 Kraken 版本号的 release 分支之间可以通过 cherry-pick 进行代码同步。

如果是手动操作，恐怕会有疏漏。

[wssgcg1213]

1. 应该需要一个文档说明支持的版本范围，然后 pubspec.yaml 里需要修改对应的版本范围，宽范围其实不保证兼容性的，Flutter 的版本号之间抽象类会变化, 没对上的话就会编译报错, 这样会更困惑吧

2. 这个点我也觉得不大好, any other ideas?

[cnryb]

1. 支持不同 flutter 的 kraken 使用不同的大版本号，不知道怎么。比如支持 flutter 2.2.x 的 kraken 的版本以 1. 开头，支持 flutter 2.5.x 的以 2. 开头
2. 感觉 GitHub actions 应该能行，得调研一下

[cnryb]

同 Kraken 版本号的 release 分支之间可以通过 cherry-pick 进行代码同步。

改为监控 release 分支的 PR，如果其中一个接收到了 PR , 使用 GitHub actions 向其他的 release 分支提交 PR，并注明关联关系。 怎么样？ @wssgcg1213
当然了，还需要吧 release 分支保护起来，只允许 PR，不允许直接提交。
为了避免自动合并出现意外（比如要合并的内容是某个 flutter 版本特有的功能），还是由咱们同学审核后手动合并。

比如需要监控的分支是 release/0.9.0 和 release/0.9.0-flutter2.2.0。
当分支 release/0.9.0 接到 PR 时，自动向分支 release/0.9.0-flutter2.2.0 提交一个相同的 PR，并且在在 comment 中备注关联的 PR 。

下面是看起来可行的证据
自动提交 PR 的方法 https://github.com/marketplace/actions/create-pull-request
获取 PR 信息的方法 https://segmentfault.com/a/1190000039125224
获取 PR 目标分支和源分支的方法 https://docs.github.com/cn/actions/learn-github-actions/contexts#github-context

[wssgcg1213]

这个方法看起来是比较可行的, 有一个点, 如果刚好提交的改动在两个分支上不兼容, 则需要手动介入此次改动, 貌似也是可行的

另外 @andycall, 我们的 ci 自动化测试也需要支持切换 flutter 版本 (https://github.com/openkraken/kraken/blob/main/.github/workflows/integration_test_flutter_2.2.0.yml) 需要确认下是否可以同时运行不同 flutter 版本的实例

[wssgcg1213]

^0.9.0

主线版本使用正常版本号, 非主线版本使用 -xxx 标记
0.9.0 (250)
0.9.0-flutter2.2.0

0.9.0+1
0.9.0+1-flutter2.2.0

[kimmy-wang]

我觉得可以参考一下Spring Boot和 Spring Cloud的版本对应关系就可以了

[wssgcg1213]

我觉得可以参考一下Spring Boot和 Spring Cloud的版本对应关系就可以了

感觉可能会比较乱, 因为同一个版本号的 Kraken 的代码在不同 Flutter 版本之间的代码差异不会很大, 所以开发过程中也倾向于类似打补丁的方式来兼容不同 Flutter 版本，所以我觉得版本号以 Kraken 为主比较合适, 而不是通过大版本号区分支持的不同 Flutter 版本

[airingursb]

有几点疑问想确认下：

1. 新的版本分支是否始终兼容最新版本的 flutter？flutter beta 版需要考虑吗？
2. 旧的版本分支，如 0.8，是否无法保证兼容最新版本的 flutter，如 2.5，除非保持每个版本都升级维护…而且因为 pubspec.yaml 的宽范围无法确定版本兼容性，旧 kraken 版本对应的 Flutter 版本好像也是无法完全确定的？
3. 什么情况下需要为版本做补丁，很旧的 flutter 版本（如 1.x）需要考虑吗，指标是什么？

[cnryb]

新的版本分支是否始终兼容最新版本的 flutter？flutter beta 版需要考虑吗？

我认为只有相近 stable 版本出现 break change 的情况才需要处理。 毕竟把精力放到 kraken 功能的演进上会才更有意义。

旧的版本分支，如 0.8，是否无法保证兼容最新版本的 flutter，如 2.5，除非保持每个版本都升级维护…而且因为 pubspec.yaml 的宽范围无法确定版本兼容性，旧 kraken 版本对应的 Flutter 版本好像也是无法完全确定的？

我记得之前有提到过 LTS 版本的事情，最多维护一个 LTS 和当前版本就够了。

什么情况下需要为版本做补丁，很旧的 flutter 版本（如 1.x）需要考虑吗，指标是什么？

同一个版本支持不同 flutter 版本的情况，才需要相互补丁。

请 @wssgcg1213 确认，我的理解是否正确。