只要交付给客户的是软件而不是一个在线服务，就不可避免的维护 n 个版本。最简单的比如维护各个版本的 Windows 系统，根本不可能用这套方法解决。

理想情况是这样的，但这只对自有产品，自己能把控发布节奏的团队有效。并且需要完善的测试 pipeline 和 review 保证有问题的代码最开始就不会进主分支。


对于很多产品来说，不同客户有不同的定制化需求。而且因为工期紧，不可能写测试，不可能仔细 review ，没有时间仔细设计导致不同定制化需求无法合并到主分支。

所以需要有测试分支给测试人员测试，所以需要不同版分支，每个分支都要单独维护。

分支管理流程不是因是果。

@maggch97 脚本本身就有热更的能力

@aloxaf 通过政策而不是技术来保证安全性就是一个笑话。

@aloxaf 并没有什么区别，绝大部分人没有审查脚本的能力，况且脚本就不能有热更的问题了

楼上说推荐 Firefox 的。

我想说这是个双标商店，比技术限制更恶心。我的插件上架 Firefox 后因为有热更新代码直接被下架了。但是一堆 userscripts 插件却在商店好好的。

时至今日，我最老的，也可能是世界上最老的还能正常日用的数码设备我想应该是 IBM model M 键盘，大概四十多年了。102 键位没变，ps/2 接口可以转接到 USB 。

同时代的鼠标甚至连滚轮都没有。

无法应对，硬着陆

@shansing
@a33291

我的系统版本和他支持的版本只有小版本号的差别，都是 22621 。我想没有人能保证系统小版本号总是能对上他发布的版本号。
及时版本号相同，也有不同的 feature flag 导致启用的功能是不同的。作者没办法测到每一种情况。


最后我理解这种插件能导致系统挂掉，但是请注意我加粗的文字！我不满的是作者自己把 GitHub 所有讨论功能关掉了！

他觉得用户反馈不重要！他觉得 issue 浪费他时间所以关了！但是 issue 并不全是给作者看的，用户直接也能交流，我如果看到和我遇到问题类似的 issue 也会试着去修。但是他直接简单粗暴的把 issue 和 discussion 功能都关掉了。我不认为这是开源项目的正确做法！

@dashjay 我在 Windows 上用过类似的 Throttle Stop ，不过只支持 Intel, AMD 没有用。

@FireFoxAhri 对的，开会时候声音都是断断续续的。我已经更新 BIOS 了，不过还没测，等我下次开会测一下。

@Moderkaiser 大部分情况都是正常的，只有在 teams 会议降频，退出来就正常了。用 CPUZ 跑分到 65W 都不会降频。

@MagicLi 正常的，已经调成起飞转速了

@Eytoyes 我看了一下 bios 版本我是 1.01 ，最新是 1.06 。不过那个更新软件必须关掉 BitLock 才能更新，我关一下升级试试

@tulongtou 插着的，电源里面我把最低 CPU 频率拉到 80%也没用。雷云里面把 CPU ，GPU 性能都拉到最高，或者风扇转速拉倒最高，也都没用

可视化的前提是有一些强力的模块已经封装好了，不懂代码的人只需要拖动一下方块就能把几个模块组合形成一个非常有用的程序。

譬如一些机器人的编程，你不需要去考虑高低电平，只需要用几个方块告诉机器人怎么做。

而不是用可视化来把一行代码转换成一个意义不明的大方块，没人有这个需要

@bmpidev2019 rpc 里面有一个 info method 的

@bmpidev2019 更新一下，使用修复后的代码，36 个活跃用户服务器占用 66M ，内存泄漏的问题也没有了。

备案所以自信？备案了不应该夹着尾巴做人嘛？想封你就封你