It would be incredibly helpful to have a list of breaking changes individual to me, meaning everything that has broken between those two versions displays in this “smart list”.
Even more helpful would be to have this list accessible right on the Supervisor → System tab under the Core box of the front end UI.
Even more helpful would be a check of breaking changes against the integrations/add-ons/entities I have set up and push relevant breaking changes to the top of the list.
It might display loss of support/complete break in red and an incomplete/partial break in yellow.
This would require the breaking changes list to have a bit more data behind each breaking change in order to display the above “smart list” to the user automatically.
The overall goal here is to further the idea that eventually this project will be easy to use for someone like my father (or wife…), and I wouldn’t expect them to look through every update post and compare all of the breaking changes to what we currently use to figure out if the update will be smooth or not.
The problem is “breaking changes” is a misnomer. Apparently it only includes intentional changes which require user action, such as editing Configuration.yaml. It is not intended to identify bugs or unanticipated failures introduced by that release.
Great! I’ll check this out. Maybe it can be used as a model, but I still think it should come standard - it’s sort of fundamental to the layperson having success with the project.
I see, thanks for pointing this out. Well, it could at least start by using this list, but I imagine it would be popular/useful enough that it would be worth adding things to the list that cause disruption to the user experience as they are discovered.
From an end user experience perspective, it should ultimately include both intentional and unintentional issues. My wife wouldn’t care why - she would just need to know what would break by updating.
In order for this work in any way I think there would essentially need to be a maintained database of such breaking changes rather than the current blog text. Who is going to create this database and maintain it? How far into the past do you expect previous breaking changes to be captured to cover the likes of yourself who haven’t updated in 4 months…?
Another part of the issue you would face is that not all ‘breaking changes’ will actually break your installation, even though you use those integrations. eg: 2021.10 had a breaking change for Xiaomi Miio which I DO use, however only the use of ‘model’ and ‘mode’ changed, which doesn’t affect me.
I agree. It amazes me that there’s no bug tracking process.
Wherein lies the problem with a system run by volunteer developers. This isn’t anyone’s job, and it’s certainly not anyone’s interest. The fun part is coding new stuff, not documenting it!
First things first, we’d have to stop referring to non-backwardly-compatible updates as “breaking changes.” Too many people assume that’s the list of all changes which broke things. But that’s not how it’s being used.