v5.0

[ForteScarlet]

等待：

• ktor 3.0 （对组件影响较大，核心库实际上没太大影响(只影响 simbot-common-ktor-inputfile )）
• kotlinx-io 稳定 ( Stabilize the kotlinx-io library )
  • 籍此更新所有跟文件、IO相关的API
  • 其实已经在 4.7.0 里开始用了
  • 标准库的 atomic API ( [New multiplatform API for the standard library: Atomics](https://youtrack.jetbrains.com/issue/KT-62423) ) #1121

考虑顺带手解决其他一些痛点：

• 更新的不兼容问题：尽量确保此次二进制兼容/向下兼容，或至少源码兼容
• 更多唯一标识，考虑为组件标识、插件等附加 application 范围的唯一ID，也方便集成一些系统，比如web ui
• 感觉botManager还是得要范型，且不再考虑允许“可能的”重复bot
• application里寻找某个bot稍微有点儿费劲，在Java里
• 基于 kotlinx-io，简化 Resource 和 (Offline)Image
• 考虑为所有组件废弃 stdlib 模块
• 还有啥？

[NoMathExpectation]

所以5.0要出了吗

[ForteScarlet]

所以5.0要出了吗

我看到 ktor 3.0 已经发布了，并且 kotlinx-io 的稳定也在 Kotlin 目前的 路线图 上了，所以我感觉 kotlinx-io 应该是快了（大概罢，实际上它这几周并没有什么动静 😟

等 kotlinx-io 稳定了，然后把核心库里跟 IO 相关的东西替换一圈儿，也就该下一个 major 了

核心库除了IO相关的东西其他的暂时也没想到有什么需要改的就是了

[ForteScarlet]

亟待解决的其他问题：

• 也许需要考虑将标准组件全部合并为统一项目共同维护？合久必分，分久必合。
• 需要重新考虑内部送信拦截和通知的形式。拦截不应该是事件的形式， 添加监听自身发送消息前/后的事件 #1016 的决定与实现的过于草率。
• 为所有组件的API考虑更好且更优的方案。在可以控制复杂度的情况下，将它们的抽象设计的更有包容性。
• 重新考虑 考虑为行为对象增加上层关系API #1047 的实施方案与必要性，结合 添加监听自身发送消息前/后的事件 #1016 一起。
• 合并组件库 #1119

[ForteScarlet]

kotlinx-io 你再不 1.0 我可就不管你了 👿