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.
1 Like