[vtk-developers] Recent API changes

[David Cole]

I'm all for backward compatibility; don't get me wrong...

I'm of the opinion that it is an extremely important feature of software 
*releases*. So, for example, I would expect that the VTK 5.0 branch is 
very largely backward compatible with VTK 4.4. Any incompatibilities 
should be documented, obvious and easy to workaround. If that's not the 
case, I would expect emails here disucussing the issues or bug reports 
to the VTK bug tracker.

But I also think it's a lot to expect of a project that still has active 
development occurring on it to be 100% backwards compatible 100% of the 
time. A cvs repository where commits are happening is inherently an 
entity that's changing and fluctuating. Developers are likely to 
introduce an incompatibility simply by mistake once in a while. A 
stable, known snapshot that is known to be backwards compatible is more 
appropriate for customers/developers that demand stability...

Again, just my friendly opinion, :-)
David

Lorensen, William E (GE, Research) wrote:

>David,
>
>Obviously, we have different ideas about the importance of backward compatibility. Something as harmless a removing an include file can cause major impact on customers outside the development community.
>
>We have some nightly builds of InsightApplications that build against the nightly VTK tree. We do this so that we can detect VTK API changes as soon as they occur. One of our challenges is that InsightApplications must build against the stable VTK 4.4 and the nightly VTK trees.  
>
>There is a great article at
>http://onlamp.com/lpt/a/5626 that discusses backward compatibility.
>
>On a related note, The Insight Software Consortium is formulating a policy on backward compatibility. It is currently in the draft stage, but soon we will open up discussion to the itk and vtk communities.
>
>Bill
>
>
>-----Original Message-----
>From: David Cole [mailto:david.cole at kitware.com]
>Sent: Thursday, January 12, 2006 4:22 PM
>To: Utkarsh Ayachit
>Cc: Lorensen, William E (GE, Research); Bill Lorensen;
>vtk-developers at vtk.org
>Subject: Re: [vtk-developers] Recent API changes
>
>
>There is little harm in keeping a single #include. However, if we must 
>always keep all #includes then they will always accumulate over time and 
>never get cleaned up even when they are no longer necessary or have been 
>replaced by something better. Projects that don't weed out the 
>unnecessary #includes compile slower and slower over time even while 
>computing power is still increasing.
>
>I think most developers understand the risks of developing against the 
>HEAD of any CVS project. Folks that need stability should be snapped to 
>a branch point or using a code base that remains stable by some other 
>mechanism.
>
>Just my opinion, of course... :-)
>David
>
>Utkarsh Ayachit wrote:
>
>  
>
>>Yes, may be you are correct. I didn't realize the impact of this change
>>given that it's assumed that people include the headers for the classes
>>they use in the .cxx file. However, if the consensus is otherwise, I
>>have no qualms in adding the header file. I again, apologize for the break.
>>
>>Utkarsh.
>>
>>Lorensen, William E (GE, Research) wrote:
>> 
>>
>>    
>>
>>>Usually there is little harm in keeping a #include. Trade this off with breaking code in the installed base.
>>>
>>>Thanks,
>>>
>>>Bill
>>>
>>>-----Original Message-----
>>>From: vtk-developers-bounces+lorensen=crd.ge.com at vtk.org
>>>[mailto:vtk-developers-bounces+lorensen=crd.ge.com at vtk.org]On Behalf Of
>>>Wylie, Brian
>>>Sent: Thursday, January 12, 2006 3:39 PM
>>>To: Bill Lorensen; vtk-developers at vtk.org
>>>Subject: RE: [vtk-developers] Recent API changes
>>>
>>>
>>>Bill,
>>>
>>>Not sure about the exclusion of that specific header file. Utkarsh will
>>>have to look into it. But I just wanted to give a general apology about
>>>the break, Kitware is doing this work under the direction of Sandia to
>>>support information visualization applications. Obviously we will try to
>>>minimize the impact of the changes as much as we can.
>>>
>>>Best regards,
>>>
>>> Brian Wylie - Org 9227
>>> Sandia National Laboratories
>>> MS 0822 - Building 880/A1-J
>>> (505)844-2238 FAX(505)845-0833                       
>>>      ____                  _    __
>>>     / __ \____  _________ | |  / (_)__ _      __ 
>>>    / /_/ / __ `/ ___/ __ `/ | / / / _ \ | /| / /
>>>   / ____/ /_/ / /  / /_/ /| |/ / /  __/ |/ |/ /
>>>  /_/    \__,_/_/   \__,_/ |___/_/\___/|__/|__/
>>>
>>>                                   Unleash the Beast
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>-----Original Message-----
>>>>From: vtk-developers-bounces+bnwylie=sandia.gov at vtk.org 
>>>>[mailto:vtk-developers-bounces+bnwylie=sandia.gov at vtk.org] On 
>>>>Behalf Of Bill Lorensen
>>>>Sent: Thursday, January 12, 2006 1:06 PM
>>>>To: vtk-developers at vtk.org
>>>>Subject: [vtk-developers] Recent API changes
>>>>
>>>>Folks,
>>>>Last week,  after a number of changes enhancing vtkDataArray, 
>>>>some of our itk code stopped compiling. I believe it is 
>>>>because itkDataArray.h is no longer being included by some 
>>>>other class.
>>>>
>>>>Was this an intentional change? What is the rationale? These 
>>>>sorts of API changes are troublesome.
>>>>
>>>>Bill
>>>>
>>>>_______________________________________________
>>>>vtk-developers mailing list
>>>>vtk-developers at vtk.org
>>>>http://www.vtk.org/mailman/listinfo/vtk-developers
>>>>
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>vtk-developers mailing list
>>>vtk-developers at vtk.org
>>>http://www.vtk.org/mailman/listinfo/vtk-developers
>>>_______________________________________________
>>>vtk-developers mailing list
>>>vtk-developers at vtk.org
>>>http://www.vtk.org/mailman/listinfo/vtk-developers
>>>
>>>   
>>>
>>>      
>>>
>>_______________________________________________
>>vtk-developers mailing list
>>vtk-developers at vtk.org
>>http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>> 
>>
>>    
>>
>
>  
>