|
|
本帖最后由 sysdiag.sys 于 2025-5-24 21:46 编辑
现有条件： 6.0产品开始，部分版本灰度时间较长，而全量推送没多久，就有了下一个小版本新灰度推送或全量推送。
需求： 这边希望该关联需求ID额外支持特性“支持始终延后推送程序版本，始终保持最佳稳定”，该功能不影响病毒库推送
原因： 比如始终等到6.0.x.1结束灰度全量推送后再更新，首个第四位数1的小版本惯例修复 首个功能特性改进中等版本更新中用户反馈的一些问题，这样 对于追求长期稳定的商业单机用户，可以使火绒始终保持最可靠状态。若没有自己反馈的内容需要修复，也不在意体验最新功能质量改进，无需第一时间保持版本最新，始终延后推送程序版本是合理的选择
就拿距离目前比较近的6.0.5.x来说，延后更新主要会待在灰度结束后停留时间较长的6.0.5.1、6.0.5.3、6.0.5.5、6.0.5.6版本。6.0.5.1是修复较多问题跨春节长假的主要版本、6.0.5.3和6.0.5.4修复了前面较长时间灰度的小版本的少量问题；6.0.5.6是6.0.6.0之前的最后一版，对于商业单机用户，会相比6.0.6.0更可靠。 6.0.5.2修复了USB触摸驱动冲突的致命问题、6.0.5.4修复了ARP防护导致的致命问题，此外这两个小版本更新内容颇多，不亚于第三位数字更新，延后推送程序版本此时可以让程序被全网反馈充分验证，避免出现商业用户所不希望的异常
算法设计：①小版本灰度结束 通常保持再次延后四个工作日到一周。 ②始终不推送中等版本更新6.0.x.0，每个功能特性改进的中等版本通常用户会反馈少量至较多小毛病。 ⑤和灰度机制一样，服务器智能给予这部分用户最稳定的自动版本更新方式
参考设计： https://bbs.huorong.cn/thread-151905-1-1.html ←“当相关版本出现严重问题时，将强制更新”，火绒从2011年首个产品诞生以来，基本未出过任何严重的问题，都是中小问题，但还是防患于未然，商业用户禁不起任何所谓严重问题。 基于本帖描述及需求ID，设计样式如图
|
|
收藏