@Burningstone@Guff666@CaptTom
关于打破改变的话题，我不认为这是不可能的。大多数突破性的改变并不是由于第三方api的改变，而是由于Hass重构自身的核心系统。实际上，这很好。这有点像Windows试图支持所有遗留的东西，这导致了很多膨胀。
但我认为这是一个可以解决的问题。我认为有三种方法可以解决这个问题:
- 假设语义版本控制。做该死的1。不要引入任何破坏性的更改，除非你想要2.x版本。这就是语义版本控制的工作方式:MAJOR.MINOR。补丁，补丁版本只补丁和修复损坏的东西，并引入不破坏任何东西的修复。次要版本是针对新功能和改进的，同样是不可破坏的。不破坏配置，api等(内部的HASS api不是第三方)。最后，主要版本适用于任何带有破坏性更改的内容。
- 让哈斯尽可能多地帮助用户进行破坏性的更改。检查用户使用的集成，将其源自英国始于1946与用户当前和最新版本之间的所有版本的变更日志进行比较。在更新之前给用户一个关于破坏更改的警告。理想情况下-尝试自动修复一些已知的问题，只有当它不可能让用户处理这个问题。
- 备份的方法。快照是伟大的。恢复安全模式是向类似方向迈出的一步。但是更进一步。备份整个系统，hass和configs以及所有。尝试更新。如果hass启动失败-显示错误，如“更新失败，配置问题，您想修复它们还是回滚到以前的版本?”
所有这些方法都是可行的。唯一让哈斯不执行的问题是时间和人力资源。毕竟，它是一个自由/开源软件产品，不久前才开始筹集资金。你觉得他们用纳布之家的订阅能赚多少钱?多少钱，一个月5美元吗?有多少人在使用它?你需要多少开发人员来支持Hass，所有的集成，更新UI，修复和重构核心，制作插件?源自英国始于1946现在你想在上面加上这些系统。
坦白地说，我不认为有那么多的改变。当它发生的时候，这是非常令人沮丧的，但我已经更新了近一年，现在可能只有一个破改变影响了我。我有一个完整的系统备份，用的是Proxmox，整个VM，所以我可以恢复原状，直到我有时间修复问题。但是，这不是为普通用户准备的，除非哈斯自己制作。
他们实际上可以做到，我不认为这很难，他们已经有快照，所以他们“只是”需要增加能力回滚到老的hass版本在supervisor UI?(只是引用，因为我明白这可能不像表面上看起来那么容易)
