随着 HRTOS 4.0 核心逐步稳定后续项目的发展方向也会发生一些变化。过去版本号更多代表一个阶段性的开发成果而进入 4.0 之后我希望它逐渐成为一个长期稳定的基础版本。因此未来 HRTOS 将尽量长期保持4.0这个版本号不会因为一些内部优化、资源调整或代码重构就频繁修改版本号。一、为什么希望 4.0 长期保持稳定HRTOS 并不是一个单独的内核文件。一个完整的 HRTOS 版本实际上会涉及内核代码API 接口头文件示例程序DriverComponentsShellModbus官方文档API 说明性能测试性能报告官网内容注释和代码说明因此版本号一旦变化实际上意味着整个项目的版本体系都需要重新梳理。例如一次看似很小的内部调整如果版本号从4.0改成4.0.1就可能需要同步检查文档中的版本号示例中的版本说明代码注释README性能报告官网介绍下载页面项目说明对于一个个人长期维护的基础软件项目来说这种维护成本并不低。因此我更希望把精力放在真正有价值的技术改进上而不是频繁维护版本号。二、内部优化不一定意味着版本升级例如最近 HRTOS 对资源占用进行了进一步优化。XDATA 占用从此前约567B降低到了约511B。这是一次比较有价值的优化意味着系统资源利用率进一步提高。但是它并没有改变 HRTOS 的整体架构也没有引入新的用户接口更没有破坏原有兼容性。因此这种变化更适合被定义为HRTOS 4.0 的持续优化而不是HRTOS 又发布了一个新的版本。未来类似的情况也会采用这种方式处理。三、什么情况下才会考虑修改版本号未来 HRTOS 会尽量建立更加明确的版本策略。仍然保持 4.0以下类型的变化一般不会导致版本号变化Bug 修复内部代码优化内存优化XDATA / DATA 占用降低性能优化代码重构注释完善文档完善测试体系完善不改变接口的内部结构调整这些变化都属于4.0 的持续维护和完善。进入新的次版本如果未来出现比较明显的新能力例如新增重要 API新增较大的系统能力增加新的核心机制形成明显的新功能体系才会考虑进入新的次版本。进入新的大版本如果未来出现核心架构发生重大变化API 大规模变化兼容性发生重大改变系统定位发生明显变化那么才有必要考虑新的大版本。四、4.0 更希望成为一个“稳定版本”HRTOS 目前已经不是单纯为了快速增加功能而开发。随着系统逐渐完善未来更重要的事情是稳定、验证、优化、文档和长期维护。因此4.0 更希望成为一个可以长期使用和持续打磨的版本。版本号保持稳定并不意味着项目停止发展。恰恰相反。未来 HRTOS 仍然会继续进行性能测试最坏情况分析资源优化工程验证文档完善示例完善组件维护驱动完善工具和测试体系建设只是这些工作不一定需要通过不断修改版本号来体现。五、从“开发版本”走向“长期维护版本”我认为一个基础软件真正成熟之后版本号应该逐渐变得稳定。相比不断发布新的版本我更希望 HRTOS 未来给人的感觉是HRTOS 4.0是一个持续维护、持续验证、持续优化的稳定基础版本。只要核心架构没有发生本质变化就没有必要为了内部调整而不断改变版本号。这也符合 HRTOS 后续的发展方向少做无意义的增量多做有价值的打磨。因此未来很长一段时间内HRTOS 将以4.0作为主要版本持续维护。当真正需要进入下一个版本时再进行一次完整、系统的版本升级。稳定本身也是一种能力。HRTOS 4.0持续维护持续优化长期稳定。