Late followup, but seems like the most appropriate place to tag on my question.
Are there any general rules (does/doesn’t) when needing to change the header interface of particular classes?
Adding/removing member data will change the allocated size for the object, so ABI-breaking even if the API stays the same. So do you manage to track a state change of a toggle, without breaking that? Or are we allowed to do that at some particular time?
Presumably it’s OK though to add new methods - different name (not just a different signature) since that would not break things?
The major/minor version numbers are added to VTK’s library names by default, so minor versions already don’t have ABI compatibility. Between patch versions (e.g., x.y.0 -> x.y.1), ABI should be preserved. API should be preserved as much as possible otherwise (deprecation warnings allow for removal after they’ve been in a release).
One would also need to consider the implication of a change. Changing the API of vtkDataSet has way more implication than changing the API the to vtkOpenFOAMReader, which has more implication than changing the API of the vtkLagrangianMatidaIntegrationModel (only examples here, but you get the point).
This all sounds good and reasonable. If there are any API changes needed (in the OpenFOAM reader, for example), will flag ahead of time to see that it all slots in nicely.