Yeah, I will look into the entities some day and I think you’re right I should be able to automate disabling/enabling incompatible updates, when I do.
I still think it should be built-in for the best possible user experience.
I mean, it’s kind of odd, it’s showing me updates I cannot install. I’ve never encountered this kind of situation with any other software.
Let’s take MacOS as an example: it will not show me an update of Safari that’s not compatible with my OS version.
The system shows update entities, there are people who want to know updates are available even though it’s not for them. That’s why they were built for automations. So what happens with that group of people if this is implemented? Do we now have to add buttons and options for the system? Where do those options go? Now there’s another system that needs to be managed in multiple places.
or…
use a blueprint / automation that does exactly what you want because you built it.
Enough said above from others about the FR. 
But this I think is not correct. If you ignore an update, future updates don’t come up again automatically, or do they? Or are you talking about HA core updates?
I’m quite sure, if you ignore an update for an integration installed via HACS, the future notifications won’t appear. But as others said, I’m updating quickly and I didn’t have that situation in over six years with HA, so can’t say for sure.
I ignored an update recently, because of breaking changes in the integration that I hadn’t had time to correct, and I’m quite sure the integration was updated inbetween. And I didn’t get an update notification.
Anyway, I’m happy as it is, but if enough votes come up, why not… 
Sure, kinda odd to me (as I said: I’ve never noticed this kind of behavior in any other software), but that’s why I included the alternative proposition in this FR:
The last option would still bug me though, as I’d like to avoid the seeing the incompatible update –> but would be a small user experience enhancement of course, change in a good direction.
I get your reasoning, but you’re asking for all this additional management. When right this minute you can get what you want without any additional management. What you’re asking for would likely need to be done by the core team because it’s a core area. The likelihood of this ever happening is extremely low because you can use blueprints and automations to do this right now.
It falls into the same category as scan_interval. Half the people want 1 button clicks, the other half want crazy intervals. So it’s an automation to appease both groups.
I personally don’t count on… votes count 
Explained here (topic for another topic, I guess ;)).
I’m personally more hoping for a “reasonable and willing” developer, noticing that there is an issue that could be solved
Sure. I believe that shouldn’t discourage me from making this FR. Or any other person doing any other FR in the future 
Not discouraging, showing you the reality of your request. Basically saying “Don’t get your hopes up”.
I’ve been using HA for a bit now, got Regular on forum → I’ve exactly knew what I was doing when making the FR
Yes but you weren’t involved in HA when the update entities were introduced and you don’t know the history behind them which lead to the current implementation.
Yep, that still shouldn’t discourage me from making this FR. Or any other person doing any other FR in the future
Things are not carved in stones…
They are after 6 years of changes to get to the current implementation that works for everyone
I’ll leave you be. Just understand that the system wasn’t built overnight and there were many systems in the past that failed (and did what you wanted).
Quite contraire! I’ve never seen any kind of system that prompts to install incompatible (apps/libs/dependencies/whatev) and then fails with an error
I was referring to past Home Assistant specific update systems. There were at least 3 other variations that I can remember using.
The current implementation was built to appease everyone and it leveraged automations so that anyone could do whatever they wanted. I’m not mincing my words here. You are encouraged to use automations and blueprints to hammer out these details you’re bringing up in this FR.
What I would want to do, is not get update prompts for updates that will break my system. I would even suggest that this should be the default.
You could still have entities that show the newest version, but not prompt the user to update if the update is incompatible.
The problem is: HA doesn’t know it’s incompatible until you attempt to install it. It’s a chicken/egg scenario. If this functionality were added, HA would need to know this information before it’s installed (which it currently doesn’t have).
Simple, just invent time travel and loop back and let yourself know P… No big.
Yeah seriously, that’s an impossible ask.
Hence: the Feature Request – construct the install/update env so that it is aware of what’s compatible and what’s not BEFORE attempting the installation.
wut wut ??
That’s impossible if the update is for outside-of-HA devices, like zwave, zigbee, unifi, etc. Your “solution” would only work for custom integrations and possibly addons.
We only find our of incompatible things AFTER people submit issues Dave. Therefore you can’t block until issues get reported.
They already have a facility to block stuff like the bum Alexa Media Player update (last month?) (and the aftermath of confusion it caused when they used it) and can use that to keep people out of critical danger but the rest of it… Yeah?
You mean for updating the devices firmware? Okeeeey, no prob, I don’t think anybody here mentioned that anyway.
Let’s focus on what can be done.
Great, that’s what I’m asking for
I guess you might be referring to what @Creeju said about “updates that will break my system”. If so, agreed.
I’d argue, should be a separate FR then This one is kinda “straightforward” IMHO.