Yes I long for this too.
Something similar to Debians unstable → testing → stable scheme.
I realise that Debian is packet based thing, and HA is not, but the basic idea can still be applied, with minimum extra work for the Ha maintainers.
For any new change to HA (feature/bugfix/…) the path should be like:
First applied to the unstable version
Promoted to the testing versions, after x days, if with no fatal bugs seen from that change.
Promoted to the stable version, after x weeks, if with no major bugs seen from that change.
I guess if you compare to the current version flow.
Unstable will match 24.12.0, 24.12.1, 24.12.2, 24.12. … ( every update )
Testing will match 24.10., 24.11., 24.12., … ( monthly update )
Stable will match 23.6.final, 23.12.final, 24.6.final, 24.12.final, … ( biannual update )
While I understand the ask, let me try to explain why this hasn’t been done before and is difficult to achieve:
The main reason for it is the same reason that makes HA awesome: The sheer amount of different integrations. Integrations are almost exclusively developed by third party (non Nabu Casa) contributors (like myself). They are almost the most likely thing to break (or introduce breaking changes) upon an upgrade, it’s almost never the “base” HA code. Saying you want an LTS release that only contains bugfixes (most likely) means you want bugfixes for the integrations as well. And that’s where the problem is.
Say we are currently on 2024.10 and I want to deliver some new feature. This will then be introduced with 2024.11. Now, if 2024.11 is shipped and someone reports a bug (that might have been already present in 2024.10) I, as integration owner, will be the one who needs to provide a fix for my integration. So I‘m going to fix it, but based on my current status which is 2024.11 and the fix would be shipped with 2024.11.x or 2024.12. If you want to include that bugfix in a patch to the LTS release, which might have been based on 2024.10 for this example, you would need to take the bugfix, but without the changes I made to introduce the new feature. Sometimes this might be possible, if I did a larger change to my integration it’s probably not (without problems). Now scale this up over a thousand times.
HA is the most active open source project. This means there are A LOT of those fixes going around. It is already a nightmare for the maintainers to manage those conflicts in patch releases as is, but having to pull them into LTS patches would either be very diffult, or not possible at all - again keep in mind they will have no actual idea what that code does, as only the ingration’s owner will really know.
Hear me out- rather than a LTS branch, what if HA made it easier to do incremental updates.
If you’ve not been keeping up, the UI just presents a link to update to the latest version.
What if it could instead offer that, or expand to upgrade to the versions in-between?
What if those in-between versions could be highlighted to mark any breaking changes in integrations used by the current install?
As a user, you could pick the latest version that has no breaking changes that impact you, then read the release notes for the next version, prepare, and jump to that one. It’d really reduce the effort to do things a bit at a time rather than having to go through tons of release notes all at once?
This is actually a really good point that I hadn’t considered.
There may still be a middle-ground, however. A Home Assistant LTS could be security updates for core-only with an emphasis on locally controlled systems.
In other words, if you want an experience like “LTS”, you would build your system with “Local Push/Poll” devices only, and only ever apply the security patches. No integrations would get fixes and no new features would be added, but that wouldn’t matter given the local nature of the setup.
Home Assistant has explicitly stated that everyone is encouraged to use “local control and open standards when acquiring new products”. Making the concept of LTS focused on primarily local setups is consistent with this goal and furthers the “Open Home” concept.
It is entirely different, offered as an alternative that may be easier for the maintainers to implement, while reducing the difficulty in keeping up-to-date. Here’s the WTH.
An individual user doesn’t use 99% of those, yet he/she has to keep pace with the updates although 99% of the changelog doesn’t apply to his/her installation.
At the moment, what is considered “core” in HA is pretty much “everything” (modulo HACS). Imagine if Linux kernel included all the distro packages, what fun it would be.
I keep reading that it is already a nightmare for maintainers to prepare releases. But what will the maintainers do when the number of integrations hits 2k, then 2.5k, then 3k?
A better model (for everyone: users, developers and maintainers) would be the HACS way: install and update only integrations that one needs. HA core could (for example) define something similar to Android API levels, requiring integrations to support a minimum (or the current/newest) level (and test successfully against that level). If there is a breaking change in HA core (affecting integrations), the level is simply incremented by one and integration maintainers are required to update the integrations if they are supposed to work with the newest version of the core.
Another reason for integrations not to be part of the core? Remember the CrowdStrike event this summer?
That approach would have its own challenges. Aside from those user experience would be impacted by integrations not being discovered automatically (before an integration is downloaded manually) and an integration very likely not being available for an update. As I said, I do agree though that it should be easier to see which breaking changes are applicable to me, as while I think there is no difference in downloading everything - breaking changes for something I don’t use I don’t care about I don’t need to see.
It should be pretty straightforward to write a (custom) installer that allows you to install a integration from a certain core release, but the chances of that integration working would be pretty slim, which is probably why no one has done this.
I like this idea a lot, where I can update the core and not the integrations if I so choose. Then I can go in and update the integrations one by one and see what happens. This is how I do it with HACS and it helps a lot, because I can just keep some of the integrations (that decide to do overly ambitious updates that just rename everything and break everything) on an earlier version until I have the time/desire to deal with the pile of work they’d like to hoist on me. I’m really surprised how long some of the old ones still work fine. Often years.
Actually, Home Assistant Core is very similar to the Linux Kernel when you consider that they both include every possible natively supported device. The various Linux Distributions are similar to HACS in that they provide drivers (generally speaking) that the Core Kernel Devs don’t want to include for various reasons.
