This problem rears its head every now and then and is particularly frustrating for ParaView developers since ParaView tracks VTK so closely. Other projects that depend on VTK updating less frequently, and when they do there is an expected amount of pain to handle API changes. ParaView developers hit that pain unexpectedly, and that is a source of major frustration. We recognize the problem, propose the same ideas, and then the frustration passes and we have other things to do and those ideas don’t get implemented (e.g., testing applications against nightly VTK, improving API change docs in VTK, etc.).
So far, IMO the best approach to avoiding that pain is to avoid API-breaking changes whenever possible. That also has the benefit of not irritating other projects that depend on VTK. I won’t go so far as to say no breaking API changes should be allowed, and some are necessary surgery on a 25-year-old patient, but erring on the side of compatibility seems like a good default. I think it is a judgement call when these changes are up for review in a merge request where you weight the cost vs. benefit of the breaking change before deciding to accept it.
We should, somebody just has to set it up. For 7.1, there is documentation on changes, but it isn’t linked in any convenient way from the main VTK documentation page.
Unfortunately, documentation doesn’t solve the problem with updating certain ParaView dependencies that depend on VTK. That has more to do with the cumbersome (but necessary) process of updating certain third party dependencies in ParaView than it does with VTK making a relatively minor API change.