[vtk-developers] policy on VTK API changes

[Michael Halle]

On Jun 2, 2005, at 9:33 PM, Mathieu Malaterre wrote:

> Michael,
>
>   I am really sorry for the trouble, but I am the only one to be  
> blame in the process and not kitware.

Mathieu,

I appreciate your response, and I just want to repeat
that this isn't a "blame" issue, for you or for Kitware.
This situation is something that could happen to anyone,
just like breaking a build.  It's not "fault", it's
a just an avoidable problem.

And just like breaking a build, we can only avoid the
problem if we're aware of it.  We've got testing to
help us be aware of compile problems, and it helps
to have policies and FAQ's to help us be aware of
unintended API changes.  Maybe we can have testing
mechanisms too, so that we don't make changes that
have consequences beyond our anticipation.  As Ken says,
there are sometimes where it makes sense to make API
changes, and knowing the ramifications of them help
us make those decisions.


>   Brad recently implemented a deprecation mechanism through  
> VTK_LEGACY. Which seems to perfectly fit for this particular  
> problem. Basically you want the old call GetHeadlightWarmth and  
> SetHeadlightWarmth to be working again ?

In this case, the changes for me are pretty small --
I don't know who else it might affect.  If the compatibility
was fast to do, maybe, but if it makes the code to crazy
or takes any real time, don't worry about it.

> If so I'll add them back, but this will give a warning a  
> compilation time, or an error if VTK is compiled without legacy.
>
> Let me know if this is alright with you,

Thanks again.

--Mike