Azide
Azide
## Why need this feature | 为什么需要这个新特性 细分更新渠道为稳定版、公测版和内测版三种可以让用户选择他们偏好的稳定性级别，同时也为在正式发布之前测试新功能提供了机会。为用户和开发人员提供更加灵活和可控的环境。 ## Describe the solution you'd like | 你希望这个新特征是怎样的 能够实现一个版本管理系统，其中包括三个不同的标签来表示更新： 1. 稳定版（vX.Y.Z） 2. 公测版（vX.Y.Z-rc.A） 3. 内测版（vX.Y.Z-beta.A） 每个标签都代表特定的稳定性级别和测试程度。 对于稳定版（vX.Y.Z），期望一个经过充分测试和可靠的版本，适合日常使用。它应该具有较少的错误和兼容性问题，为所有用户提供稳定的体验。 对于公测版（vX.Y.Z-rc.A），期望一个包含新功能和改进的版本，但可能仍然存在一些小的错误或兼容性问题。这个版本适合愿意测试新功能并提供反馈以帮助改进软件的用户使用。 对于内测版（vX.Y.Z-beta.A），期望一个主要用于开发团队内部测试的版本。它可能包含实验性的功能，不建议一般用户使用。这个版本将允许开发团队收集反馈并解决任何关键问题，然后再将这些功能提供给公众使用。 ## Additional context...
目前的nonebug在测试时遇到和期望不相符的文本时，只会显示这样的格式： ```python f"Application got api call {api} with data {data} but expected {model.data}" ``` 这经常会造成如下对人眼检查不友好的输出: ```python Application got api call ... with data {'foo': 1, 'bar': {'hello': 'world'}} but expected...
原先的30s对叔叔而言还是太敏感了
命令: `停止订阅 ` 效果: 在调度时忽略该平台或者目标，不进行请求 目的: 主要是为了在触发B站风控（使用新Api）后不必关闭掉整个Bison或者手动删除B站的订阅，从而不影响其他平台的蹲饼 初步实现思路以及问题: 可以在scheduler的schedulable_list中添加一个disable以表示是否禁用？但这样缺乏持久化。或者在数据库中也添加一个新字段？那么对整个平台的平台的禁用应该如何实现？为scheduler添加一个disable_platforms进行记录？那么怎么持久化储存？
bison的现有的配置开始变得复杂起来了 加上以后可能还需要按platform配置，感觉得加一个自己的配置文件了
未启用配置`BISON_USE_BROWSER`时有些Platform不会激活，不应该出现在订阅命令
Congratulations on the release of the first version of the Python bindings! 🎉 As I mentioned in issue #559 and in the `bindings/python` documentation: > Access to data of message...