Last time I skipped a few months of updates I had so many issues that I couldn’t work out, due to too many errors (before safe mode was a thing) that I just started fresh…
Would be nice to see an LTS, but the issue is soooo much changes it would be hard to roll up. Python versions, Python package versions…
Last time I skipped a few months of updates I had so many issues that I couldn’t work out, due to too many errors (before safe mode was a thing) that I just started fresh…
Would be nice to see an LTS, but the issue is soooo much changes it would be hard to roll up. Python versions, Python package versions…
This is exactly the syndrome I want to fix.
Updates wouldn’t cause so many issues if they were simply leaving out the breaking changes (not always possible, but many of them are simply because someone wants to change a naming convention or something), and no new features (which are the cause of the majority of other breaking changes). You could update python versions every so often, that has rarely caused me major issues. I believe that you could even leave pyscript and other things on other versions as I don’t think they need to use the same version as homeassistant.
The bigger issue I find is that basically every .0 release breaks things, and they are usually fixed in .1 or .2
It shouldn’t be this predictable that the .0 release will break things.
The bigger issue I find is that basically every .0 release breaks things, and they are usually fixed in .1 or .2It shouldn’t be this predictable that the .0 release will break things.
This is not really the issue I’m trying to solve. I want to bring breaking changes to the absolute minimum. Minimize bugs too, but that is more a side goal than the main goal of stopping breaking changes (and with it probably most new features) in exchange for a system that can still be up to date with bug fixes, latest cloud API’s, etc and not break something in most upgrades.
Yes, this please! I’m always behind 2-3 months in HA releases which I guess is not great for security, although my HA instance is only acceptable via LAN, still not great.
My thought exactly 
Sorry to say that the thought of updating a year old installation is terrifying at best.
Don’t get me wrong, I LOVE most of those new features and part of me wants it all. Immediately.
But what would REALLY be a decent update strategy for a system that’s supposed to be stable in the first place?
I’d see it something like the final release of each month with all the breaking changes stripped out. If they can keep the features without the breaking changes, then move on. I’m sure it wouldn’t be that simple, but that would be an awfully nice goal. So you could update each month or when you felt like it, but you wouldn’t have to worry about things breaking when you did.
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:
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.
This is entirely different than the proposal here and warrants its own WTH imo.
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.
You got my vote on that one 
And my axe vote!
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.
We are at 3k
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.
