I understand that you feel that minimum and maximum values and the threshold function should be rather treated as three independent properties. However, the ThresholdBetween/ThresholdByUpper/ThresholdByLower API has been around for more than 25 years and it is still used in 9 other thresholding filters in VTK; and thousands of VTK-based projects rely on them.
To summarize, what I’m hoping to achieve by keep spending time with this conversation are:
- Revert this unnecessary breaking API change (by merging https://gitlab.kitware.com/vtk/vtk/-/merge_requests/9709) to save thousands of VTK users from some frustration and wasted time. The API change could cost the open-source community $100-200k effort that could be better spent elsewhere.
Cost estimation of vtkThreshold API change in open-source projects
Sampling of usage of ThresholdBetween on GitHub indicates that this change would impact thousands of projects. Assuming one hour workload to manage this API change per project (find the root cause of the issue - non-trivial in Python code, because the problem does not come up at compile time; implement a solution that works for both current and older VTK versions, test the solution, in a few years remove the backward-compatibility code) the damage to the open-source community alone is about $100-200k. This money could be spent on much better things then managing unnecessary API churn. To see some of the noise that the deprecation has started to cause see these recent issues.
- Make sure that in the future, breaking changes are introduced into VTK API only with a very good reason. Maybe some rules could be established and described in the VTK coding guide that would help making well balanced decisions.
Since this discussion does not seem to converge to a solution. I would appreciate if other VTK core developers could share their insights. Maybe @ken-martin or @will.schroeder? Thank you!