You can hang back a release and only install the last dot release of each major release.
There was another core update yesterday, because, hey, why not.
Yup, you canāt (effectively) deploy commercially with this strategy, it needs something approaching LTS for many scenarios.
Of course Iāve seen products go too far the other way of course, like Indigo Domotics, where you wait 6-18 months (or longer) for a specific (potentially critical) ZWave product to be added.
As a hobby, HA is perfect, tinkererās paradise. But someone paying me for work doesnāt want a hobby project, they want something thatās bulletproof and doesnāt change between the time I install and the time of the agreed-upon maintenance schedule.
LTS would be ideal of course, but probably too much to ask for at this time. The way this project is managed is pretty much in total opposition to an LTS release.
But even a standard stable release would be a big improvement. While you can do it the way @tom_l mentioned, that also comes with risks. Not all dot releases can be considered stable. Often problems such as memory leaks (which are surprisingly common with HA) appear and take more than a month to fix. Known āgoodā dot releases should be tagged as such and new users, or users with a desire for a stable platform, should be encouraged to officially install those. Sadly Iām afraid the chances of this happening to be rather slim though.
HA is a great hobby project for tinkerers and developers, but I would never even think about deploying it commercially. Itās not built for that. The liabilities around breaking updates would be unmanageable. Youād have to pin a version and never touch it again, which is very difficult without an LTS release.
9 times out of 10 this is not the core. It is third party integrations or people abusing the available script loop syntax.
I experienced 3 memory leaks myself over the past 1.5 years roughly, one of them is still not fixed to this day. Iāve managed to work around it. All of them in core.
Not my experience from reading thousands of posts here.
Welp, what can I say. They didnāt magically disappear because people post a lot about ādumb leaksā on here too. My strategy has been to drastically reduce my dependency on (core) integrations, not use any custom integration besides pyscript, then try a dot release that looks more or less stable, possibly switch to another if I encounter issues (which iirc, happened twice so far). Once found, I usually stick with this version for half a year or more.
Where as I run a huge number of core and third party integrations and participate in the beta program with little if any issue.
Iām not denying you have issues with your particular set-up, but it does appear you are over stating the problem for users in general.
Youāre not running a supervised install are you?
Alright then, thereās no point in discussing this further then I think. Maybe I got unlucky. Who knows. The laws of probability say Iām probably not the only one though.
Iām running core in a venv btw.
Edit:
Hereās number one #69695 (stream)
Hereās number two #70340 (stream)
I canāt find the third one, but it had to do with the recorder.
Here some more memory leaks from this year, all in core:
#77767 (ZwaveJS integration)
#67143 (SSDP)
#83661 (stream)
#72544 (onvif)
#82504 (onvif again)
#2180 (HAOS)
Just randomly by browsing the github issues. I could go on.
I think you might be underestimating just how many memory related issues are in core. The good news is that they usually get fixed quickly and the devs are usually very reactive.
2 Likes
If you update the supervisor to version 2026.03.3 you can not update any apps (formally addon) if the supervisor update is set to false.
Just to update all, the supervisor was changed (on purpose) that unless you have the auto update flag turned on you can not update any app.
Iām not seeing the behaviour you described.
I have the flag set to false so that I can choose when to update the supervisor. I updated to the latest supervisor version earlier today. I can still update apps. I just updated ESPHome.
I canāt and the issue I posted was close and I was told this is WAD and now it does not allowing app updates unless supervisor is set to auto update.
I still have the flag at false (but am on the latest supervisor version) and just successfully updated two more apps (Mosquitto MQTT broker and Advanced Web Terminal).
Thanks for checking again. Iāll set mine back and see if it will work again for me. According to Stefanās answer it was changed and will no longer work. I did in the past and I would update supervisor manually when i was home and then any apps. It stopped (for me) working like this a few weeks ago.
What OS version are you on?
I have not yet updated from 17.1 to 17.2.
I am on 17.2. I still donāt understand Stefanās rational for making this change. He said it was a supervisor change.
Iām wondering if what he said was incorrect.
I think he might have meant that you just need to be on the latest supervisor version. Thereās nothing in the original PR (that introduced the flag) he referenced about needing to have it set to true to update apps. Just that you need to be on the latest supervisor version. Falling behind will disable updates. It was a bizarre reply.
Iāve updated to 17.2 and will let you know if I can update apps when another update comes in.
If you read the issue I believe I asked this clearly and he said that unless it was set to auto no apps could be updated. I was on the latest supervisor and OS when it failed, I changed the flag to auto and the apps updated. Iām a sample of one so maybe it is an issue with my setup? I hope so as I donāt want automatic updates on anything.
You can try adding a new app. It did not allow this with auto update off.