Ideally the upgrade process should warn if an active integration has been removed before the upgrade. Similarly, the UI should give politely persistent warning notifications if deprecated integrations are in use.
There have been a couple cases recently of upgrades breaking installs. The 2022.4 removal of the legacy zwave integrations are a prime example. It was announced as deprecated months ago, and was warned of in the release notes.
Users should have known better, but users (almost always) don’t do as they should.
Removals and deprecations are not really prominent in the release notes, and unless the user also upgraded the month a deprecation was announced, they would be clueless to the warning.
The average user NEVER looks at logs unless something is broken. Telling them after the fact anything along the lines of “you should have noticed” is just rubbing salt in their wounds.
Users who fail to read deprecation announcements, published months in advance as well as in the Release Notes, are the same users likely to promptly click the “Next” button for a warning that appears during the upgrade process (for the same reasons they currently skip warnings: It was too long to read/I didn’t understand it/I thought I could deal with it later/I didn’t think it applied to me/Why wasn’t I warned before the upgrade).
It’s a reasonable FR but I doubt it will be implemented. Anyway, good luck and don’t forget to vote for your own FR.
It is the type of “fit and finish” feature painfully lacking in too many open source projects. A not too difficult feature, but boring and uninteresting to the devs capable of turning it into a PR.
For a general market product, expecting average users read any release notes past the new and shiny bullet points is a fantasy. Average users don’t expect an upgrade to break things, not accepting that fact is folly.
It is the type of thing that needs to be done if there is any intent that Home Assistant Blue, Yellow, Purple, Red, etc ever be general market appliances.
If the intent is to keep HA inside the open source, github aware, forum monitoring sphere of users, then so be it.
That’s part of the problem. It’s not reasonable to expect any but the most techie users to read every release note every month. For geeks like me, that’s fine, but HA is expanding well beyond the techie market.
There’s only so much that can be done.
The message needs to be appropriately scary, require a checkbox acceptance, etc.
It would be important to limit the upgrade removal warning to in-use integrations for the local install, not a generic “the following items have been removed…” message. If it’s the exception it’s more likely to get noticed, if it is routine, it gets ignored.
Perhaps not for those reasons but more likely for this one that you mentioned:
There’s only so much that can be done.
It’s a matter of diminishing returns. Tens of thousands of users successfully upgrade their systems and tackle the Breaking Changes (and some deprecated features) that come with each release. Those who expect to blithely click “Upgrade” and receive immediate guidance, for navigating breaking changes/deprecation, may have to wait a long time before someone volunteers to implement this degree of hand-holding.
I believe this Summons it well, and most likely same reason your requested “Procedure” not have higher priority than new ( user requested features and product support ) and bugfixes related to same.
Sure it might avoid some(few) Topics created here in the Forum, few … but most likely will “some” just change the focus from ( i didn’t know ) to ( yeah but this shouldn’t break my system/functions ) something like that … so basically a 3-4 step verification/control/accept/don’t complain procedure wouldn’t reduce post here in the Forum, and neither people behavior. We are who we are, and in most cases we repeat our behavior endlessly, either by neglecting, forget or moving borders
I think you underestimate the impact a simple change can have. Maybe I’m overestimating. It should be relatively low hanging fruit, and I look at it and think been there, done that, fixed that.
Similar changes to have eliminated support head count at more than one company. Of course, those were environments where techs were expected to answer the phone and work through any problem. They couldn’t just say “RTFM, thank you, goodbye.”