in the system log file…that nobody ever looks at unless something is broken right now… How is that considered the best way to inform users that something will break in the future?
I’m sure every one of those ways that you have discussed the change is perfectly reasonable for your core developers. What about the non-core developers who make one or two components to solve an issue that they have and then decide to post it so that others who have the same need can benefit from their work and never revisit the component after that? Those people can’t be expected to follow all of those listed discussions continuously on the off chance that their component might break later on. Not to mention the users of those components who installed it and it worked perfectly fine until one day it didn’t (and didn’t happen to look at a link that was specifically aimed at “developers”). And now both of those groups need to wade through the breaking change lists, and in this case possibly old breaking change lists, to try to intuit from the (tbh, at times kind of poor) documentation to try to figure out what went wrong.
And I’ve tried to jump in the Discord chat to get help once or twice and IMHO that is the worst way possible to try to get help on a problem. Maybe it’s just me, but I don’t think so, but I find trying to wade through the stream of consciousness format of that channel is way too difficult to follow when you are trying to wrap your head around a complex/confusing topic.
Since I’m not a “developer” and I’m not involved in all of those discussions taking place in those locations the only thing I can reasonably do is try to point out to the people “in the know” where there is confusion. Most of the time that effort is met with disdain from others (kind of like this and the other thread) who then “circle the wagons” and act like this is some sort of “sacred cow” that can’t be criticized or, even worse, the problem is completely ignored. And not to mention the extraordinary amount of time I spend on this forum almost literally every day with a lot of that time spent trying my best to help other people figure out how this stuff works and fix problems they are having while trying to figure it out myself at the same time. I think that counts for something.
And I already gave a recommendation on what I thought could help with this in the other thread. The other thing that I suggest (and have suggested before) is to provide more detail in the breaking change listing in the release post of exactly what the change was or somehow annotate the docs to indicate what the change was. Right now the way it’s done by just pointing people to the new updated (??) documentation is almost useless to figure out exactly what changed since no one has the docs memorized to know what they looked like before to allow them to figure out what is different now.
But I’ll also make a better effort to try to fix the documentation where I think that I can reasonably make it better. Again, not being a developer my knowledge of the nuances of the code is pretty limited and is based completely on what is already in (or frequently not in…) the docs on the HA main website.
Please don’t get me wrong I love this software and I really appreciate the work by all of the “official” developers and especially the “non-official” one-off developers who improve HA on a regular basis. But this software is literally nothing without the support of people who use it and the documentation and announcements should be aimed at those people. Not the developers who already know all of this stuff in the first place.
OK, so right now I’m using 12 custom components, 8 of which add to a pre-existing official component, 4 of which are “sensors”.
When a developer creates a new custom sensor component then all of the files for the official sensor component have to be copied over and included in the directory for every new sensor component created? So you will have multiple replica’s of the same file over and over again in different sub-directories in the custom_components folder?