I’ve found HA to be stable for some time, not a lot of breaking changes with the integrations that I am using.
What are you seeing break all the time? Are you using a 3rd party integration? Maybe we can help you get upgraded and then you’ll be good to go.
Even the recent naming changes in Automations are optional and will automatically be updated when you save the Automation in the GUI.
Right now my appdaemon is broken after the last update. Everything else is working well, hence my desire not to update and break anything else.
I do agree that this situation is getting better, but there are still breaking changes in every update. And I don’t use the GUI for automations.
This is a really good one. I could imagine a lot of people (including myself) cannot keep up (time-wise) with monthly updates and would prefer to spend half a day every 6-12 months to do a major upgrade.
As an example, Portainer’s STS and LTS streams might serve as an inspiration: Lifecycle policy | Portainer Documentation
Yep I am amongst those updating for the sake of updating and keeping my fingers crossed that it doesn’t mess up things. Normally it doesn’t but you never know…
Yeah! - was also my opinion
less features
more bugfixing
bugfix releases/LTS Branch PLEASE
the number of bugs I have to deal with was growing in the last 12 month … with most of the releases. the bug reports mostly stuck
Yeah. I love every new release. But I have to skip every first minor release until the first or second patch to keep my system stable. I had some trouble in the beginning while updating to every minor version as early as possible. It would be nice to setup a LTS repo/line to only get minor updates after they are really stable. For people that don’t have the time or knowledge to tackle some complex errors or non-functional Integrations after an update.
I would suggest to use the Linux kernel scheme here.
The core maintainers of Linux only care about the new stuff, git HEAD and such. But there are people — often from Linux distros — gueared around just one LTS maintainer that create the stable release.
What is the benefit?
Maintaining a stable release obviously takes times. This time would be removed from the current git-HEAD developers. And also some doing this kind of maintenance is often not as rewarding as working on top-notch new features. So it is, at a personal level, not appealing to everyone.
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.
Maybe a proven stable release could be marked as LTS and only security updates are applied to that version?
Just a thought… 
Keeping up to date is getting harder and harder. The gratuitous UI changes that mean you have to rebuild chunks of dashboards on a pretty regular basis mean I am getting less and less inclined to do it. I know it’s bad, but they need to separate out “fancy new features” from “security updates”, so I can run a 6 month old HA that still gets security patches, but not dashboard breaking “new experiences” that are just scratching some UI dev’s itch to try the latest fun widget, and break everyone who has an existing setup.
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 )
