Implicit in your post is the suggestion that things MUST operate this way, that every breaking change should and must require every user to react with every release.
Are there no alternatives? Can we, as members of a community around this project, come up with a better way to handle this?
Alpha aside, breaking changes are still going to occur, just less. And @luma is trying to just discuss ways to handle it.
Currently we handle it after the change occurs. He’s looking for ways to discuss prior to the changes, to potentially reduce the breaking changes.
What alternatives do we have? Take a look at this thread. A breaking change is occurring and the USERS on this forum came up with a solution prior to release:
I guess one way to handle it would be to create a topic for breaking changes and possible solutions that are being edited on the first post? Instead of “spamming” the blog post about it to rather collect them?
Avoidance of breaking changes in this kind of project, at this early stage in the lifecycle will result in overly complex code for the long term. Decisions which were made with the right intentions but have, with hindsight, been wrong get baked in and workarounds rather than fixes are implemented. Leading to massive maintenance issues long term, code bloat and a host of other issues such as bugs and security vulnerabilities
This is alpha software and anyone using it should understand and accept that it comes with caveats.
If there’s anything wrong, it is that point is not made clearly enough for newcomers.
To keep this thread on-track, allow me to throw out some ideas.
Several times in the past we’ve seen phase-in for a breaking change where a warning will be thrown for several versions when a particular statement is encountered. Eventually, a release will be issued where the configuration is officially deprecated and Home Assistant will fail to load.
This may still be required for substantial changes to an individual component, but there are a whole lot of situations where a particular statement simply doesn’t make sense anymore due to other changes that were made in the component.
For example, the vizio component long ago had a problem where it would log spew due to the self-signed SSL cert used by Vizio. Instead of fixing the problem, a configuration value suppress_warning was added to the component that would simply silence these errors.
Later, the issue was resolved somehow and the suppress_warning statement was deprecated. Anyone who had implemented this workaround now had to go back and remove the workaround or Home Assistant wouldn’t load.
Maybe, instead of breaking Home Assistant, one could simply ignore the deprecated configuration statement, and possibly log an error somewhere to let the user know it was happening? This is done temporarily, why not just leave it this way so we don’t break things that have no bearing on the user’s configuration?
Obviously this does not fit all breaking changes, but addresses some subset that otherwise would require user attention.
The first commit to master was in 2013. Seven years later, are we still thinking we’re in the “early” stage of development?
Its nothing to do with time, it’s to do with the stated position of the project. It is not a v1 released application. Any one basing their config or the config of their ‘users’ on that needs to accept they take the rough with the smooth.
It feels like your argument boils down to “there’s nothing we can do”. I feel differently, I think there might be some ideas we can agree upon collectively that will make the upgrade experience better for everyone.
Certainly agree that some of these breaking changes could be posted in this forum for (quick?) discussion / opinions before being implemented in, what to some can feel like, an autocratic fashion.
The one that comes to mind, for me, is the state_color: discussion that permeated the .105 Blog post/thread.
Seems an RFC: Breaking Change - Automatic Icon Color thread started in the forum could have elicited quick, honest, likely even helpful, feedback - before users were upset at the already-been-implemented change.
It clearly wouldn’t makes sense to create RFC threads for EVERY breaking change, but seems some of them could benefit from proactive solutions / productive comments vs. reactive frustration.
Certainly realize that it’s IMPOSSIBLE to please EVERYONE regarding EVERY change - SOMEONE will ALWAYS be unhappy w/ the decision. Also not looking to consume valuable developer time/energy reading forums / opinions on every change…
Yes, which is why I keep hammering on the ‘who is going to do this’ aspect. I’d personally rather have new bells and whistles and improved performance over breaking changes. Which can be actively ignored by not updating.
There might be ways to improve things but there is no perfect solution. Some points I haven’t seen mentioned.
Some people like breaking changes for various reasons. They see them a positive movement. They see them as fun and things to tinker with that relate to a hobby they enjoy.
Breaking changes aren’t always Home Assistants fault. Many cloud services change APIs, discontinue products, etc etc etc that are out of our control.
The powers that be have already said in some form that they aren’t too worried about having breaking changes before 1.0. After that I think they will re-evaluate and see.
Here’s another idea:
There are situations where a breaking change has an obvious and universal fix. Again, this won’t be true for all changes, but there have been loads of situations where the change was something as simple as renaming a configuration value.
What if we could somehow make the change for the user?
Spitballing here, maybe when the config value is deprecated, on next load of the UI for a user with admin permissions we present a dialog with a short overview of what config value has been deprecated, a link to documentation explaining the issue in further depth, and an offer to edit the configuration file for the user?
Again, this won’t work in all cases but there are a lot of examples here where the only change required would be a simple rename of one value to some other value. If Home Assistant created some sort of internal hook to register these kinds of changes, the developer issuing a PR could fill in the appropriate values to deal with text and links to be presented to the user, and Home Assistant would have the mechanism to prompt the user and make the change available as a standard feature. Then, require any “simple rename” PRs to provide the required interface before being accepted.
This feels like it could be low-hanging-fruit.
This is already in the works. The shift to the UI solves this problem. It’s only a matter of time before everything needs to be configured in the UI. Mark my words, while they are not explicitly saying that this is the case, there will be a day where yaml configuration is gone.
I can’t really account for people that like to have things broken for them so that they can fix them. Maybe implement a Home Assistant Chaos Monkey to address the needs of these users. The rest of us would be happy to have that time back for more pressing matters.
Totally understood and acknowledged. Home Assistant has to change quickly, because it’s dealing with outside systems who APIs aren’t controlled by the community. I’m arguing that we might be able to do a better job of managing these changes.
And I’m arguing that this approach places an unnecessary burden on the user community at large. Again, it seems like we might be able to do better.
I believe this was actually done for a release last year. For .92, the google tts integration was renamed to google_translate and configs were updated automatically at upgrade.
I definitely do get where you are coming from, but I will say that things have improved a great deal since I’ve been using Home Assistant. The stated goal has been to make things more user-friendly and approachable for the version 1.0 release, and I certainly think improving the breaking change process plays a big role in that.
I think there are two pieces to the puzzle here. One is the actual burden of implementing fixes to breaking changes. I don’t think there’s a ton that can be done to mitigate this currently. At least until we hit 1.0, some continued breaking changes will be a necessarily evil.
However, the second piece is cutting the time down to actually review breaking changes and determine impact. I do think the time estimate you gave is on the extremely high side (I know you stated in a later post that it was a very rough estimate, but when you put something in the title like “25 million minutes a year” when it’s likely not close to that, it comes across as a bit clickbaity).
In terms of reading the release notes for breaking changes, I would think most people would want to read the release notes anyways to see what new features have been added before upgraded. I know not everyone does this, but if they do, the breaking changes are really only a small subset of the total release notes. So some of that five minutes per release you mentioned really is time that would be spent reading release notes regardless. Most people are not going to be impacted by most of the breaking changes, so the process often ends here.
I also use the add-on that checks the configuration against the latest version prior to upgrading. This helps catch issues before I upgrade, and then if there is something that’s invalid, I can review the breaking changes in more detail.
Finally, there is also the Breaking Changes component in HACS that can eliminate a lot of the scanning through release notes. I think that between these three things, catching the occasional breaking changes (and they really are a lot more occasional in terms of impact to individual users than they used to be) is relatively trivial.
This is actually a major component of my argument as presented above. Even if I have no fixes to make, I don’t know that unless I review every single breaking change, with every release.
This brings me to my next possible solution…
Thanks for pointing that out, I did not know about it! That’s super neat
This has often been implemented for a lot of changes but it could be made a requirement of the PR process (emergency changes to deal with outside API changes excepted).
That’s what deprecation means… They usually provide deprecation warnings for months. Case in point, Lovelace and the states page which prompted this post from you. The warning was provided that states was going away at some point in the future last year. Yet you sat on it until the release of 0.107… I hope you see the irony here.