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 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.
Provide a warning for (nearly) ALL breaking changes at least 2 versions prior to enforcement
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.
Yup, but not always. Maybe it could be better if it was enforced as part of the PR process?
When that happened I posted a thread, which you have replied to, in February of 2019. In the year between that post and now there had been no resolution to the problems presented.
Because what you want doesn’t make sense. I’m sorry that you might have to do some work on your custom project that you provide to people. You should have realized that when you provide a solution you need to support said solution. It’s not a set it and forget it scenario. And your users should know that because they are using a custom solution.
I have been using HA since ~0.25 and the work done by the contributors/developers has been phenomenal. While there are ‘breaking changes’ for the most part they are better documented, and less disruptive than they used to be.
I do try and keep up with releases so that I don’t have to parse the breaking change list for multiple major releases, but even then we usually get some grace period to get things cleaned up. Additionally, using the check-config add-on before updating is a helpful safety check.
As an example to the 105 release announced the deprecation of some view configuration settings (which I had) that will be deprecated in 107. I was pleased to find out that I had some poor configuration that HA had been working around for a long time.
I’m trying to make this about helpful suggestions to make the Home Assistant upgrade process better for everyone. I appreciate you might not think my problems outlined in the other thread are real problems. This isn’t about that.
Thus far it feels like the overall reaction is that the way things are today is the way things must be. I disagree, I think we can do better and the project will be better for it.
I agree - but as many people have pointed out, it is going into this direction already, and I am sure myself, that v1.0 will be user friendly to that point of checking and adapting breaking changes on the fly.
But as of now, I am happy enough with the product and with the work that not only the devs, but many many people here are developing and sharing, so I do not mind applying the breaking change fixes myself and spending time on my hobby.
There are many tools and even more helpful and nice people here to get you through the upgrade.
I believe that managing a breaking changes thread on its own instead of using the blog post, and maybe even announcing them before the release would be even more helpful
No, I think it could be done better. But what you need to understand is how the current paradigm works. You can’t throw out github and it’s process. That’s impossible. So you have to work within the confines of how github works. The only way we can handle breaking changes before they occur is by discussing them when the changes occur in the PR, or have discussions prior to the PR’s creation. Because we have no control over the PR’s creation (anyone can create a PR), our only option is to discuss it on the PR itself. Therefore, there needs to be a manager of the PRs. That’s currently one of the developers, but he only manages weather its placed into the software or not. Also, it shouldn’t be on the developer to make posts and raise awareness about breaking changes. That’s a full time job. So, what do you propose now that you understand the process a little better?
Example: My company has a dedicated person who talks with consumers and gets software feedback. That’s his whole job. He drives what we put in the software. We let him know when things are going to break. He makes the documentation to help the users or we discuss ways to get around the breaking change.
The Home Assistant project already has a set of requirements for accepting PRs. Some of those requirements are automated checks, some require manual review. Most of the suggestions I’ve made above could be made part of that process.
I’m not even arguing for an extended “dispute” process. I acknowledge that breaking changes are going to happen, this isn’t what the thread is about. I’m soliciting ways to better deal with them when they do. Take a look at the suggestions above, you’ll get a sense of what I’m on about.
You’ve helped me out personally on several occasions and your depth of knowledge on this platform is incredible. I would wager you might have some ideas of your own on how best to improve the user experience…