docs: 拆分 ChangeLog

[guimc233]

现在这个 CHANGELOG.md 体积… 真的会有人去看它吗

[guimc233]

甚至 GitHub 网页直接打不开 changelog 了

[zqfan]

保留完整的记录还是有必要的，要解决的问题是堆积在一个文件中查看不方便，以及超过github默认解析大小的问题。直接删除很久以前的changelog估计不会被接受，但我想可能可以按年拆分，在默认的文件中记录最近的变更。我得和仓库的维护者沟通下

[guimc233]

保留完整的记录还是有必要的，要解决的问题是堆积在一个文件中查看不方便，以及超过github默认解析大小的问题。直接删除很久以前的changelog估计不会被接受，但我想可能可以按年拆分，在默认的文件中记录最近的变更。我得和仓库的维护者沟通下

我认为近期的 changelog 可以按照 npm 包的版本进行拆分, 写在默认 changelog 文件内, 可以更方便的查看某两个版本之间 API 的变化
较为久远的 changelog 可以直接按年(或是按月) 存档

[guimc233]

例如:

[fz6m]

可参考 vite 的 CHANGELOG.md ，以每一个 minor 版本为粒度，链接到历史 tag 对应的 CHANGELOG 即可。

考虑到历史上 CHANGELOG 一直是全量发布，CHANGELOG split 可以作为未来发布时的方案。

[cweijan]

@zqfan 这个changelog本身就是不合理的, 除了纯文本编辑器, 几乎都无法解析这个markdown文件, 这个文件也没有任何的可读性和可维护性.

[eiinu]

一般是每个 major 版本会重头写，但是这个 sdk 的版本发布规则也太奇怪了，上千个 patch……

[vndroid]

其实都想得太复杂了，完全没必要。Changelog 批量替换为：

- 解决了一些已知问题。

就可以了。

[rogtino]

可参考 vite 的 CHANGELOG.md ，以每一个 minor 版本为粒度，链接到历史 tag 对应的 CHANGELOG 即可。

考虑到历史上 CHANGELOG 一直是全量发布，CHANGELOG split 可以作为未来发布时的方案。

雅

[wuliaodexiaoluo]

commit 其实完全可以写点有用的东西，不要一个劲的 Release xxx，这东西也能当 Change Log 的（但可能不是什么最优解）

[TimothyYe]

其实都想得太复杂了，完全没必要。Changelog 批量替换为：

- 解决了一些已知问题。

就可以了。

这是在内涵微信吗

[zeyudada]

其实都想得太复杂了，完全没必要。Changelog 批量替换为：

- 解决了一些已知问题。

就可以了。

太内涵了，哈哈，连续多年都是这样

[rbqvq]

其实都想得太复杂了，完全没必要。Changelog 批量替换为：

- 解决了一些已知问题。

就可以了。

不够, 应该是

- 解决了一些已知问题。
- 移除了 him

[rbqvq]

保留完整的记录还是有必要的，要解决的问题是堆积在一个文件中查看不方便，以及超过github默认解析大小的问题。直接删除很久以前的changelog估计不会被接受，但我想可能可以按年拆分，在默认的文件中记录最近的变更。我得和仓库的维护者沟通下

CHANGELOG改成目录

目录里面按年份月份分类得了
比如 2025-02.md

或者 major.minjor.md
例如 v3.0.md

有一说一你们 go sdk 那边tag真的该重新弄了, 20w个tag太多了