I am currently undergoing an upgrade from a 2021 June version to the current one. I’m finding soooo many broken configs due to the latest versions not being backward compatible. Most of the changes are also just opinion based where maybe a bunch of devs argues about terminology and decided to change commands because it makes more sense to them.
OK, making sure terminology makes sense is important to some degree, but not at the cost of backward compatibility. At the least, the old configurations or structure could also be supported. Over 2 years, my old system was broken in such a way that it jus could not be upgraded, nor was I able to take to recover backups any more!
Eg, Changing the term “snapshot” to “backup” at the cost of breaking the ability to back up or restore older systems is not an acceptable decision.
In my upgrade process (as yet unfinished), I’ve found the following features broken due to lack of backward compatibility:
Ability to back up/restore - This happened automatically because the system upgraded it’s self at some point without an option.
I’m sure, you will say that if I had kept up to date regularly, then I wouldn’t be facing these issues all at once. But the point of home automation is convenience and simplicity. We shouldn’t have to be constantly staying up to date and researching the latest breaking changes every month.
It would be nice to build and leave it alone for a couple or more years and once in a while do a major upgrade to to take advantage of any new features (if any).
there actually is a period of time for backwards compatibility but when you go years without an update you usually go over that time period. I do agree with backwards compatibility but it needs to be continuously maintained and no one has time for that it makes code tougher to read and not as lean. Eventually you need to switch to the new setup.
Only the supervisor auto updates, unless you specifically enabled addon auto updates. There is a method to disable automatic supervisor updates but you may end up with an unsupported system.
I don’t know about this one.
Legacy template format is still supported for backward compatibility and there are no plans to remove this. So nothing should have broken whith this.
As I said in your other topic, this is a security feature.
My point is exactly that! We shouldn’t need to read through all monthly release notes every month to find if something we have is being changed without backward compatibility and in the past 2 years I’ve found 4 show stopping changes in just my implementation. How many more are there that didn’t affect me?
This is the one critical issue that made my original install impossible to upgrade (no way to backup and restore in case of issues). I wasn’t aware of any way to stop it from auto upgrading. I’d be happy to set it up that way and leave it at the same version forever if it means it will keep on working.
Anyway, if low maintenance isn’t a product priority, then it is what it is.
To be honest, everytime I update my HA on Virtual Box either something breaks or is in the configuration.yaml or it completely messes with the VM.
For that reason I go on updating maybe once in every year and when I have the required time to research all the breaking changes.
But then again, it might be a problem with my current setup.
But that’s the reality for Home Assistant at this time which is a open source project and involving rapidly. It’s only logic for the dev to don’t look back because the majority actually uses the latest and greatest version (~50% latest, ~83% use one of the last 5 releases and only less than 17% run a version older than the last 5 month)
But - as HA is open source you can just fork () it and make a LTS version (just can’t name it HA) which focuses on stability & bug fixes and avoids new features. Still if you go down that road (or pay some one to do it) you might find out sooner or later that things are breaking anyways because upstream dependencies exist - and not only a few! The wish for low maintenance might be not much more than a wish
Do you read the breaking changes at all before updating and act accordingly (if you needed)?
I do usually read the breaking changes. For example I had a couple of Dlink smart plugs integrated in Home Assistant, which Dlink stopped supporting. A month later in the HA update, the support was dropped also, bricking my devices even though cloud connection had been off from Dlink and working fine in HA.
I had read about that breaking change but decided to update since my VM would randomly freeze or go 100% on the CPU.
As a rule of thumb: the longer you avoid updates, the deeper the hole becomes.
At a certain level it might be easier to “just” take a full backup (while still possible ), do a fresh install and restore the backup - still things can (and will) break so best is just to stay “ahead” then fall behind
Imho it is actually easier to invest the 5-10 minutes once a month to coupe with the update (and possible breaking changes) than to wait a year and find out that you are not able to “just” get your system to the latest version within 1-2 hours due to a possible cascade of breaking changes
And one more for the people of fear of introducing new bugs with new versions: don’t update directly to the point zero release (like 2023.8.0) but just wait two weeks more for the point release(s) which typically include possible bug fixes (like 2023.8 .2)
It might just make it easier having a fresh working HA system running and restoring partial configs step by step to identify the particular ones that might break HA. Also changes around the OS made on the old HA system will also be gone - a fresh start guarantees no skeletons in the closet
It might be a lot easier for someone in the position of the OP if it were easier to incrementally apply the updates since they last upgraded, addressing the breaking changes in smaller chunks.There’s probably a way to do that already, but I’m not aware of one to grab anything but the latest version via the UI updates menu.
The point of this post was to consider making new versions compatible with previous configs. So that we can update HA to a new version and take advantage of new features without the need to revisit previous functionality (avoid releasing intentional breaking changes in the first place as a design principle). Keeping up with all changes on a regular basis is an overhead most end users don’t have time or technical skills for.
I found even taking and restoring backups was broken at some point. Really?
But I think the feedback here has established that the ethos of HA is continuous, always hands on maintenance by the home owner. End users are expected to perform regular review of documentation and maintenance through incremental updates, or occasional major rebuilds potentially as a complete new install.
So HA is not for the ‘set and forget’ or light touch types of users. Those users will be in real trouble in the event of hardware failure and the need to restore a pre-existing, existing setup.
This is not an argument. Just establishing a core design principle and identifying the target user base for HA. Ordinary, none technical home owners with lives of their own, or dedicated hobbyists committed to continuous tinkering for the life of the system?
You have to keep in mind the HASS really isn’t a fully mature product yet, and has never been advertised as such. But it definitely come a long way! There used to be WAY more major breaking changes. I think they will eventually become a trickle as HASS matures.
But as others have mentioned, some breaking changes are due to upstream changes and third party issues and those ones will never go away.
For comparison - Google is constantly finding ways to break Google Home / Assistant without even really documenting the changes and they are a multi billion dollar global industry leader so I personally think Home Assistant is doing ok how they are handling changes and the rapid pace of development. It’s been a long time since there were any crippling changes for my config.
Missed the point. Release daily or yearly for all I care. It’s the breaking changes that are the issue.
But quite obviously, you’re very active and contribute a lot. That’s great and I genuinely thankyou. But for people like me who have other life priorities, I just can’t afford the time in either a single complete rebuild or regular monthly refactoring.
Not sure how you manoeuvre there but if you had a running healthy system - if it is 6, 12 or 18 month old shouldn’t matter - you should be able to take a backup which is considered more than useful prior doing an update.
In case the update went south there is no need even to try to resuscitate the old system but quickest win is to install HA fresh and then restore the backup just taking before the failed update attempt. Still it’s possible that things break and in that case best bet is to start HA with a fresh empty config and only restore the backup partially to get a clue why things are failing.
What end users should this be? I would describe a typical HA user as combination of technical skilled and having (too much?) spare time
For the first user group plenty of choices do exist. The typically ones come with great limitations (compared to HA) but often offer very simplified functions which even allows non tech savvy user to do simple stuff in their homes with the help of other people computers ()
) it and make a LTS version (just can’t name it HA) which focuses on stability & bug fixes and avoids new features. Still if you go down that road (or pay some one to do it) you might find out sooner or later that things are breaking anyways because upstream dependencies exist - and not only a few! The wish for low maintenance might be not much more than a wish 
), do a fresh install and restore the backup - still things can (and will) break so best is just to stay “ahead” then fall behind 
)