Issue Description
当前情况
PaddleSpeech的PyPI包已经严重过时。上次在PyPI发布是 2025年5月23日（版本1.5.0），到现在已经将近 一年 了（当前日期：2026年3月14日）。
与此同时，GitHub仓库本身维护得其实还不错，最近仍有代码提交和更新。从去年3月到现在，很多重要的bug修复和改进都已经合并到develop分支，但都没有同步到PyPI。
问题所在
这种版本滞后造成了项目质量的误导性印象：
-
用户通过 pip install paddlespeech 安装的是一年前的旧版本
- 新用户按照"快速开始"文档安装使用，会遇到很多早就修复了的bug
- 这给用户的印象就是：PaddleSpeech这个项目bug很多，维护得不好
-
具体例子 - CTC Endpoint的Pydantic v2兼容性问题
我遇到的这个问题就很典型：
# 运行流式ASR服务器时报错：
[ERROR] - mutable default <class 'paddlespeech.server.engine.asr.online.ctc_endpoint.OnlineCTCEndpointRule'> for field rule1 is not allowed: use default_factory
这个问题其实 早在GitHub上就已经修复了（改用 default_factory 处理可变默认值），但因为PyPI包没更新，用户安装时还是会遇到这个错误。
-
用户被迫使用变通方案
为了解决这些问题，用户不得不：
- 手动修改安装文件（可能引发其他问题）
- 从源码安装（对Windows用户不太友好）
- 或者干脆放弃使用这个项目
影响
- 新用户的第一印象很差，可能直接就劝退了
- 浪费开发者时间去排查早就修复的问题
- 项目维护状况被误解，给人"bug成堆"的错觉
- 阻碍项目推广，尤其是习惯用pip安装的用户
为什么值得重视
PaddleSpeech这个仓库本身其实 维护得挺活跃的，代码质量也不错。但就是因为PyPI更新不及时，导致用户通过pip安装时遇到各种已修复的bug，从而产生"这个项目bug真多"的印象。这本质上是 版本发布流程的问题，而不是代码质量问题。
建议
希望维护团队能考虑：
-
尽快发布更新版本到PyPI
- 哪怕只是发一个patch版本（1.5.1），把积累的bug修复打进去也行
- 或者直接发1.6.0版本，如果有重要新功能的话
-
建立固定的发布周期（比如每季度或每半年一次），确保：
- PyPI包与GitHub源码保持同步
- 用户有稳定可靠的安装体验
- 减少已修复bug的重复反馈
相关链接
备注
@zxcd - 这个问题直接影响音频相关功能（如流式ASR服务器）的用户体验。
感谢维护团队对项目的付出！及时更新PyPI版本能极大改善用户体验，也能让项目真正展现出它应有的质量和活跃度。
Issue Description
当前情况
PaddleSpeech的PyPI包已经严重过时。上次在PyPI发布是 2025年5月23日（版本1.5.0），到现在已经将近 一年 了（当前日期：2026年3月14日）。
与此同时，GitHub仓库本身维护得其实还不错，最近仍有代码提交和更新。从去年3月到现在，很多重要的bug修复和改进都已经合并到develop分支，但都没有同步到PyPI。
问题所在
这种版本滞后造成了项目质量的误导性印象：
用户通过
pip install paddlespeech安装的是一年前的旧版本具体例子 - CTC Endpoint的Pydantic v2兼容性问题
我遇到的这个问题就很典型：
这个问题其实 早在GitHub上就已经修复了（改用
default_factory处理可变默认值），但因为PyPI包没更新，用户安装时还是会遇到这个错误。用户被迫使用变通方案
为了解决这些问题，用户不得不：
影响
为什么值得重视
PaddleSpeech这个仓库本身其实 维护得挺活跃的，代码质量也不错。但就是因为PyPI更新不及时，导致用户通过pip安装时遇到各种已修复的bug，从而产生"这个项目bug真多"的印象。这本质上是 版本发布流程的问题，而不是代码质量问题。
建议
希望维护团队能考虑：
尽快发布更新版本到PyPI
建立固定的发布周期（比如每季度或每半年一次），确保：
相关链接
备注
@zxcd - 这个问题直接影响音频相关功能（如流式ASR服务器）的用户体验。
感谢维护团队对项目的付出！及时更新PyPI版本能极大改善用户体验，也能让项目真正展现出它应有的质量和活跃度。