Another idea for a first step : an addon (or part of hass) that lists all changes to your implementation in newer versions. Breaking and non-breaking. Then from this “module” you could manage changes/breaking changes.
Step 1 Could be list the changes categorized by breaking and non-breaking.
Step 2 Could be link or describe/link how to fix a breaking change.
Step 3 Could be to add buttons to “resolve” them.
Though this idea would not do stuff automagically. OP sounds like he’s looking for a more automagic solution.
Reading this thread, my mind kept going back to the recent change around the automatically generated groups as one where I think it could have been handled better, given it was an ‘internal’ change.
My reading of the comments from the development side and the user side is that that function was being used in ways it wasnt necessarily intended so it’s impact was possibly understated. To me (admittedly someone who was unaffected), it was possibly a good candidate for some pre-warning (one or two versions ahead of removal) and possibly discussion - that way the impact of the change could be mitigated.
I think (and this is not a negative at ALL) that the Devs just do not care about this. They want HA to conform to their long term vision and a lot of old stuff just doesn’t so they are breaking stuff to align everything for the future. Fighting this and arguing about it isn’t going to change anything.
I’ve been here for 3 years now and ‘suffered’ through lots of breaking stuff but I do 2 things to keep this to a minimum… 3 actually…
I ALWAYS update to the latest and if there is stuff being depreciated I adapt immediately. I fix stuff that will change in the future NOW. With the pace of development, if you get behind, it’s often easiest to start over.
I run the betas. If you do that, you can report stuff that breaks or otherwise comment directly with the Devs on discord and sometimes they listen but pretty much they always fix stuff. I have only had to roll a beta back a couple of times.
If there is a new way to do something I will always switch to it… eventually if you don’t it bites you. (Lovelace vs States as an example)
It has been my own observation that the Home Assistant user experience is heavily slanted towards a developer’s mindset. What doesn’t seem like a “big deal” for a developer might be perceived very differently by a less-technical user.
That’s because developers run the show. I don’t know how else I can spell this to you: There needs to be a non-developer (community ambassador), or a community that communicates with the developer. You keep glossing over that, but that’s really the only option. I’ve yet to see you come up with anything else other than a pip dream. I’m being a realist here. There are limited resources and we have to live within those confines.
Home Assistant currently has in place a breaking changes automated solution. It fills your requirements most of the time. In the past year, I can only think of a few breaking changes that are outside your ‘2 version’ requirement. Those seem like snap decisions but when you dive into it, there is typically lengthy discussions between the devs. But no input from the community. The only way to get input is to bridge that gap. I’m not trying to blow smoke up your ass, there are MANY ways companies do this right now. Just take a look at AGILE for example.
Nearly all of the suggestions I’ve posted above (with the exception of “fix it for them”) require no additional input from the community nor any major modification to existing practices. They could be enacted as simple guide rails around the PR process enforced using existing mechanisms.
Let’s just use one of the suggestions here as an example: “Don’t crash on deprecated configuration statements”. This could be implemented as a requirement for accepting a PR. If you’re deprecating a given configuration statement, instead of breaking on load, have the component accept and ignore the no-longer-pertinent statement (maybe with a log message saying it happened).
All I’m pushing for here is to tighten up the PR process with some common-sense approaches to minimize the number of breaking changes and their impact on the end user. Today, we allow a lot of breaking changes to have far more impact than they should. It doesn’t need to be this way.
We’d have to move away from voluptuous as a yaml/json validator. This would be rejected. You’re essentially asking for a totally new system that doesn’t care about validation. Which might I add, would break all these nice errors for the config checker. And why put work into this when they are moving everything into the UI? A community manager would gently let you know why this wouldn’t be the right decision. The benefits of leaving this in do not outweigh the repercussions.
I’m not sure I understand why that would be true. The deprecated YAML option would still be ingested, just ignored by the component. Check the link back to the original statement where I use the vizio component as an example. Instead of breaking the config when that option was no longer needed, one could still accept that option, log a warning, and do nothing with the option as it no longer applies. How does this break validation?
It breaks future validation and leaves unused code, test cases would fail unless kept there as well. You’re asking for more overhead than you think. Now the dev’s have to maintain all this extra overhead code to keep some users happy. Why not make it easier from the get go. Not to mention the option is deprecated. This alone means it’s getting removed in the future. That’s the whole point of deprecation. And it doesn’t crash when deprecated, it warns you. When its removed it fails configuration check. Still not a crash, it will now go into safe mode.
No, you aren’t looking at the bigger picture. The goal is to make the user experience better, long term. You’re looking at short term happiness. Remember, limited resources.
I also know that if you are not reading the releases in detail and ‘just getting on with automating’ ( I know of some users who haven’t upgraded in months too ) Then this stuff just accumulates.
You are proposing that they just let the detritus build
At what point does this become unmanageable as I can’t find the bit that’s broken for all the other bits that don’t work and are just getting in the way ?
TELL me when there is something wrong - AND I’ll get up off my fat ass and fix it
You missed the part where I said “log a warning”. You have the log trace to tell you when there is something wrong, but it doesn’t need to break Home Assistant as a requirement of that notification.