Then I must have misread something, but I really remember reading something about the Supervisor being depreciated. I seem to recall that you were in that thread as well, some 6 months ago or so.
Found the thread:
It was about this time that I bought a second Nuc to run the HA image. (Glad I did). This lets me keep my Ubuntu on the first Nuc.
Maybe what you remember is Home Assistant Supervised being deprecated? That’s what it states in the link you posted.
Supervisor is a management module included in two installation methods:
The plan was to deprecate the second method, namely Home Assistant Supervised. Due to pushback from the community, the plan was cancelled (but with some constraints documented in ADR-0014).
Unless you use the old legacy zwave, this is entirely possible with openzwave (beta) or zwave js.
I keep seeing references to “ADR-xxxx”. As if it’s obvious. What is an “ADR” and where should we be watching?
Architecture Design Rule
Unfortunately that was the only integration I got going with my RPi and Aeon Stick Gen5+ so I’m guessing I am soon out of luck.
That’s the problem, you are guessing. When Legacy ZWave (1.4) deprecation was announced, it came with a caveat:
The only way Legacy ZWave (1.4) is getting deprecated is if it stops working. This will only happen at major python releases. When python 3.8 is removed from HA and 3.10 is added, that’s the next barrier. I highly doubt Legacy ZWave (1.4) will stop working then. You most likely have years before that integration stops working.
Sounds like a guess too 
Not really, something major would need to happen in pyd files for it to suddenly fail. To put it into perspective, those files alone haven’t changed in 5 years.
It’s enough that HA will change its API breaking the compatibility. Does depreciation policy ensure updating component code to be up to date with API or compliant with other requirements?
What are you talking about? Who said anything about changing an api? Are you on this forums just to give people grief? Next time you feel like replying to me with nonsense, just move on.
You said
The only way Legacy ZWave (1.4) is getting deprecated is if it stops working. This will only happen at major python releases. When python 3.8 is removed from HA and 3.10 is added, that’s the next barrier. I highly doubt Legacy ZWave (1.4) will stop working then. You most likely have years before that integration stops working.
I’m asking if is it really the only case it might stop working.
Yes, it is. It’s stuck using OpenZwave 1.4, so the pyd files are static because openzwave is static. Everything from that point upwards (the integration) is still being maintained.
Initially I did understood “depreciation” differently. Now it’s clear.
Thanks for answer.
This is a ‘special’ deprecation. Normal deprecations are announced and then axed at a later date. Zwave legacy has no ‘axe’ date and there are no plans for an axe date. When it stops working is when it will be removed. This is the only deprecation like this, mainly because it’s so widely used. The deprecation was not by choice either, it was forced on HA by OpenZwave.
I hope that is done as that is how openhab does it. Most users of openhab don’t update the core very often and it just keeps working, should a new integration come along you can keep the stable core and just drop in the new file in and it works. If an integration has a bug you can drop in the older version with whatever core you want. Mix and match to find the winning combo.
Of course that can make supporting a user a huge pain when they don’t just use the latest version. There are times when an integration requires a brand new core feature and it won’t work on the older cores, so yeah it makes things more complex. I have often found HA to fix one bug I needed fixed but that update broke a few new things so it was like rolling the dice trying to get it all to work.
Just about to turn it back on and roll the dice on it again.
Interestingly, tho, unless something has changed, I believe most of the devs don’t actually use HA OS or especially Supervised. My understanding that most use HA Container or Core.
It seems it’s a recommendation that has limitations or every dev/advanced user would be using it.
I was in agreement with you right up to here.
The issue with that approach is that if you don’t update until you have to then you will be forced to deal with every breaking change in your config for every update you skipped.
It’s way easier to fix them a bit at a time instead of fixing all of them at once.
I’d imagine the reason for them using Container or Core is most likely because they are mega nerds that do all sorts of other stuff on the same machine, things not possible with HA OS.
No it is because a venv is easiest to develop on, you don’t need to build a new docker container every time you test some new code.
Right.
Limitations. 