出问题再说 
不会有人给自己的配置写自动化测试吧 
3 个赞
有问题的话一般编译包时就报错了，不放心可以直接recompile一遍看看warning，虽然有的包本来就一堆warning。
每天都更新，测试不了一点
每次更新包都会用 straight-freeze-versions。没发现问题就不管照常用，等到了发现出问题了，如果有正事就直接用 straight-thaw-versions 回退版本保证可以正常使用。有时间了再看怎么修复配置。
4 个赞
当然是出问题再说，Emacs 是工具，不是我们测试上线上市的产品。
优先使用stable.melpa.org的包, 定期用elpa-mirror备份所有包.
1 个赞
感觉有些功能就跟降落伞一样, 平时注意不到, 用到的时候发现没work, 影响就很大.
那么emacs作为一个庞大生态, 用法千奇百怪, 有什么办法保证最终集成的可用性吗?
我去研究一下, 至少能方便回滚.
保证最终集成的可用性
review 每一行变更的代码
顺带一提，emacs30+集成了vc-use-package，用:rev关键字可以回滚包到上一个commit
1 个赞
elpa-mirror.el
备份功能真的是太棒了, 一两分钟内就可以重新安装所有包, 要是更新包有问题, 能快速回退
straight 用起来比自带的 package.el 复杂一些，但是有这个 lockfile 的机制就足够我选择并一直使用它了。用 lockfile 自动管理版本还是很方便的。比手动管理版本（比如手动指定 git commit hash 或者 tag version）或者手动备份软件包仓库要方便很多。
不过straight的这套 lockfile 机制在实现的时候、也做了一定程度的 hack。比如为了能够锁 elpa 的包版本（很多 elpa 的包都是按照 tag release 发布的，根本就没有 git 仓库 更别说 git commit hash），专门写了一个 github CI 会给每一个 elpa 包都创建一个 git repo，并定期拉取 elpa 的包的更新为每一个 elpa 包都自动生成 git commit，因此 elpa 包锁的版本其实是自动生成的 git repo 的 commit hash，而不是 elpa 发布的tag 版本。但是这个并不影响版本更新以及回退的稳定性就是了。
当然，melpa 的包基本上都是有自己的 git repo，所以通常都是锁项目本身的 commit hash 版本。
1 个赞
但再好的静态分析也无法替代动态测试…
再完善的动态测试也会有疏漏的地方，也无法保证最终集成的可用性。
而 review 看不出来问题，只能怪你自己的能力不够
保证可用，得有你自己来保证。
是的, 我就是在找一些工程方法保证可用.
因为配置, emacs, packages都在演化. 我相信emacs本身和packages肯定大体上都有比较好的质量管控, 但是整体它们和我的配置集成起来是否完善, 其实是失控的, 只能靠packages+emacs的向后兼容性.
我是使用 Borg 通过 git submodule 管理第三方包，大量更新包或者重新编译Emacs后，都会在本地执行一次 make clean && make build，用一段时间，如果没问题就提交并推送到 Github仓库，这时就会自己运行配置好的 Github Action 进行测试，如果有问题会有邮件提醒。
如果本地的升级完就出 Bug，那就快速回退版本先用着。但一般做升级时基本都是在有空时弄，升级出的问题大部分都很好排查（因为有 Git 控制版本，可以 bitset 二分查问题），几下就修好了。
这是我个人使用的配置，供参考：
Git Submodule 是最佳包管理器， 没有版本控制的包管理方案都是对自己不负责任， 会永无止境的折腾， 而没有时间研究技术。
