I doubt that. Every release is littered with these types of complaints whether the change in question is plastered in your face or not. I know because I monitor it now. I’ll offer up the suggestion to add supervisor PR’s to the blog post releases. Or maybe a supervisor blog post release seeing that it’s technically not tied to Home Assistant’s releases.
The red text should be yellow, indicating a warning message. Home Assistant maintainers said the Home Assistant Supervised would be maintained for Debian officialy. For others Operative Systems, the community will do it. @kanga_who and other people are doing a great job maintaining the script for most used Operative Systems, like Ubuntu and Raspberry Pi OS.
The red text is aggresive, it seems that this method will be deprecated, but Home Assistant Maintainers said this won’t be deprecated, so it is a bad choice in my opinion
1 Like
I’m not sure it needs to extend as far as all PRs if that is what you are indicating, however, when something significant is being added/removed, such as red text informing the user their system is unsupported - that’s important information that needs to be shared prior to the change.
Hopefully, you can see the distinction.
Not everyone reads the breaking changes or release notes, that is obvious, but I don’t think that should discourage anyone from listing significant information in blog posts.
Unless of course that is exactly what you want…
Agreed
Yellow text on a white (default) background… maybe more of a orangeish-yellow because yellow on white is eye burning 
1 Like
Suggestion accepted 
100% agreed!!
Certainly I think that proper release announcements of new supervisor releases would be helpful, for the very reason that we are discussing. Yes I agree that
Every release is littered with these types of complaints whether the change in question is plastered in your face or not.
but at least us readers would know to expect a change.
I also see constant changes to frontend, which seem to be on their own release pattern, without ever knowing what to expect!
2 Likes
The fact that these updates are forced upon the user is also a source of irritant and displays a certain arrogance - we know better than you do. It is just like Microsoft’s attitude and that is not a good comparator.
3 Likes
Maybe, just maybe, the change was made to inform users of how to fix their supported supervisor instance. You all realize your upset about the color of text right? Color. In the grand scheme of things, is that really a game breaker? I just don’t get it. If this text was white and your supervisor instance broke, you be mad it wasn’t red. From my perspective, the devs can’t win. No matter what, there be people upset with them over basically nothing. This is just my opinion, do not confuse me with a dev.
8 Likes
It appears that was the intention, however, no instructions we given on how to fix it, just a link to a page saying what you needed. Adding in a simple set on instructions on how to fix the message would have been helpful. Just giving a link that “allows one to figure out what is wrong.” is not the best way forward.
Incorrect, at last for me. The issue is the lack of communication about the change being made. Make the text white, yellow, pink, it doesn’t matter - communicate it beforehand in a way that users can understand with a method on how to resolve it. That wasn’t done, that is the problem.
They could help themselves a hell of a lot more if they communicated better. There are so many instances of reactive communication around updates on these forums.
There has been dozens and dozens of posts in this thread since this change was made, most of which have been discussing this change, arguing for or against it in some way. Imagine if some simple communication and some instructions was given before that change was made, this little fire may never have started and everyone’s time could have been better spent.
Yes, people will be upset every time there is an update that changes something they are used to, but in this instance if a simple set of instructions were given on how to resolve the problem and some reassurance that their install was not going to break, that would have eliminated many posts and questions in this thread, and the many other that started up with users not knowing what to do, or how to fix their install.
8 Likes
Couldn’t agree more. I posted before, 200 some replies ago. This is a hobby for me, this is not my job, nor is it something that I want to spend hours a day figuring out. Nor is it something, even if I did spend hours a day figuring it out, would my wife still be married to me.
I was on a raspberry pi 3 a year ago and found it to be underpowered. I then found juanmtechs YouTube tutorial on how to install ha on my recently purchased from eBay nuc.
I then stumble across this thread stating how this install method was ‘illegal’
Weeks and months after this thread stated my supposed install method was illegal there is still NO officially supported install method nor tutorial on how exactly to install and run a non-hassos version of ha on a Nuc.
now I’m simply left with a red error message stating I’m running an unsupported install with no easy route forward.
so you’re saying that I’m running something that I shouldn’t be, but you’re giving you no path to go forward with the route that I should be, save for installing Hass OS on my nuc and eliminating all other options to use its power for other programs. or you’re giving me the alternative to go figure out proxmox or raspbian and Debian and all these things that as a somewhere between power user and newby don’t know about and honestly don’t care about.
End of rant but give users with a device more powerful than a pi a clear route to leverage the full power of their device without reducing its usage to only running hasso and ha.
2 Likes
I’m 100% positive this was a simple oversite. It was something that was added as part of the share diagnostics & crash reports.
Hindsight is 20/20. Easy to say that now when you see the argument before you.
As I’ve noted in a number of threads in the past, and this one, it is a reoccurring theme - reactive commentary due to lack of communication.
It’s got nothing to do with hindsight, it’s got to do with people not taking on the feedback that changes need to be well communicated and documented in advance. It’s been noted and discussed ad nauseam, yet it doesn’t seem to be sinking in.
Let me give you an analogy.
I own and work in my own business, a restaurant. Lets say today I make up a new pasta special, Spaghetti Pescatore, and plan on running it for dinner service tonight.
I reprint my specials page and put it out on the clipboards ready for my team to use tonight, yet say nothing about the specials changing. My team come in and start their shift, and check the specials page. They see the new special, but have not been given a description of what is in the meal, potential allergens like garlic, chilli, price, cooking time, etc. One by one they come and see me to ask about the special, and I have to tell them all what is in the dish, over and over again.
What I should have done is placed a description of the meal alongside the specials board for my team, with all ingredients in the dish, allergen notes, price, preparation time etc. This eliminates the need for them to question me about the dish, they all have the information they need to answer any questions the customer may have.
Now, if I continue week after week to keep changing the specials and not giving my team information on the changes, is this their fault when they get shitty with me when they have asked over and over to be told, or is it mine for not learning the lesson that they need the information to do their job properly?
8 Likes
There have been a LOT of infuriating major changes this last year none of which have been communicated well so it’s not hindsight as such it’s a pattern. A lot of goodwill is being pissed away for no reason - it’s no wonder people assume the worst and are suspicious.
8 Likes
think you mean unsupported. totally different things
2 Likes
And we wonder why the devs dont interact here and they stick to discord where they can interact with other devs. its just to toxic towards them here
2 Likes
I’m not sure I agree it’s toxic, but it can get a little out of hand, from both sides sometimes.
Which came first though, the chicken or the egg? I ask because I don’t think people naturally become aggressive about something unless it’s something repetitive happening that really starts getting to them.
2 Likes
If you feel that way, what can be done to correct it? Do you have a solution?
Here’s mine. Document every change and update the documents accordingly. Then if a user chooses not to read the docs, it’s on them not the Devs.
1 Like
This is already done. Go check out github for the change set. That’s all I did.
I offered the solution to add every Supervisor PR to the blog post list and you shot that down (even though we do that for core). 