About API breaking changes

[mwestphal (Mathieu Westphal (Kitware))]

@utkarshayachit

Having the onus on the VTK developer to ensure no dependent projects are broken is just not feasible. Imagine the QVTKWidget changes you were working on a while ago. Now imagine doing those changes tracking down dashboard failures on all dependent projects!

I absolutely agree and this was never my suggestion. I merely suggested that developper that already work on VTK and VTK dependant software (like VTK and ParaView for me) test the VTK dependant software (only ParaView for me) locally before merge as they already have the expertise to do so.

@utkarshayachit

Having ability for buildbot to trigger builds on dependent project has indeed been an idea we’ve discussed and deemed useful. It’s awaiting developers to take on the implementation.

Great !

@lassoan

I would expect that VTK developers do a lot of testing and planning to avoid major regressions in releases . However, I don’t think we should try to control more tightly what happens in the VTK master , as any extra requirements would just put more burden on VTK developers.

Regression should not happen in master if testing is done right, but in any case, this is about API changes. My Second suggestion would improve the release update process by providing a compiled document of all the necessary changes in dependent software. We more or less have a similar mechanism in ParaView where we document important changes in .md files. Should’nt we have something like that in VTK in order to help VTK software dev to update their VTK internally ?