The breaking changes list only describe the change and maybe have a version number for a completed transition.
I would likw to have the version number for when the breaking change took effect too and it would be nice to have this on the first view somewhere and not just in the extended description.
This info would make it a lot easier to see which breaking changes that are new and which that are older and already taken into account in my current configuration.
I assume you are talking about ha release notes. They are always talking about a specific version. eg if 20xx.yy lists a breaking change it is a change in 20xx.yy. it won’t be referring to an earlier version. Nor a later version.
Ok, I just thought I stumbled over breaking changes that carried over.
One last question before I withdraw the feature request.
Can there be breaking changes in minor releases, the z in xxxx.yy.z?
I can find no info on this and that is actually where I am using most of my time rereading breaking changes notes.
I believe the answer is no.
I can’t recall seeing one since I started using Home Assistant almost 4 years ago.
What have you seen that made you submit this Feature Request?
Well, it actually a lot of small annoyances.
I find myself checking the breaking changes again and again, when there is an update, no matter if its a major or minor, because I could not find any info that clearly stated that a minor update could not have breaking changes.
I also often try to help other users on the forum and I know that there is a breaking change that cause the error, but trying to find that info can be cumbersome, since the complexity of the search increase a lot with each extra release that have to be searched.
What I would really like is actually a kind of database for braking changes with info for
Combine these entries with a sort/filter and it would be possible to see breaking changes over several versions of HA, for seperate code parts/integrations or what is imminent required changes due to warning modes being reached.
So what you’re saying is that despite looking for it in countless minor releases, you have never found one. You won’t give up trying to find one unless you find official documentation that they never put Breaking Changes in a minor release. Is that correct?
If it’s documented, I don’t know where. For example, the current versioning style and release schedule was only introduced in December 2020 and is mentioned in a blog post. In contrast, my understanding that new features only appear in major releases and minor releases only get bug fixes (“patch release”) is based on something I read by either frenck or balloob written either in this community forum or elsewhere but where exactly I no longer recall. Similarly, Breaking Changes are limited to major releases but I can’t point to developer documentation that states this practice.
I can’t say and that is why I keep up the habit of checking everything again and again, but it is becoming a bit tiresome.
I’ll make it easier for you:
Which one of the two applies to you?
There is a good basis for wanting to get a big list of breaking changes by version. Reading the individual release notes is tedious.
All breaking changes are listed as such on GitHub. There must be some kind of search available.
All closed Pull Requests tagged with the Breaking Change label:
https://github.com/home-assistant/core/pulls?q=is%3Apr+is%3Aclosed+label%3Abreaking-change
I challenge anyone to find a “Breaking Change” PR that was merged into a minor release.
A little late to the party, but hey 
I find it interesting, that I’m not the only one, who is not satisfied with the status quo regarding the new releases or better the communication about it. 
I’d support something like a databased solution, it would make things much easier to read. Just for the first overview. But I’m happy, that after suggesting it seven times the minor releases get a link in the top section of the blog post. 
But that seems to be something for the future, as there simply isn’t a head of communication in the HA team. And I can see why the developer team isn’t the right place for such things to happen. I’m known for an extensive writing, but even I would have problems, if I’d try to be that exact in my projects. It just isn’t something that should be handed or better laid on the shoulders of developers, it really isn’t their job.
And if you see who is responsible for the release posts and assumingly all the stuff around it, it will most likely stay that way, we will have to “fight” for not letting it get worse Seriously, Frenck seems to be a decent guy, but he isn’t “THE” communication guy. Not that I’d blame him for that, I’m quite sure, the development of a communication strategy isn’t part of his job description. He is a developer for the software and will most likely just have missed his chance to say “no”, when the topic came up.
Long story short, I’d happily get into a community project, where a few people set something like that up. I’m quite sure, with a good concept, we could win over the dev team, if we would need something adjusted like a different tag on Github or a thing like that. And if the solution is good, there will be a place for it on the HA pages.
So, who’s first?
The FR is moot. It requests adding a version number to Breaking Changes that are already grouped by major version. The Breaking Changes in the Release Notes for a major release are for that specific major release. Any subsequent minor releases for that version are limited to bug fixes and don’t contain new features or more Breaking Changes.
Except the topic’s author would prefer to see this policy in writing (well, not my writing anyway) because they’re convinced minor releases can contain Breaking Changes (but hasn’t actually ever found one to prove that theory).