[Insight-developers] ConceptCheck & Wrapping : ITK 3.4 Update
Luis Ibanez
luis.ibanez at kitware.com
Fri Sep 21 10:55:25 EDT 2007
This sounds indeed like the right thing to do,...
*for one release*...
but...
We shouln'd understimate the cost/effort of maintaning
such a system for the next five to ten years.
This brings up the deep philosophical question of:
"What is the expected life span of ITK ?"
5 years ?
10 years ?
15 years ?
20 years ?
Do we want 20 years from now to have ITK version 43.4
to be backward compatible with today's ITK version 3.2 ?
or only with ITK versions 25.4 and higher ?
How far in time does backwards compatibility extends ?
E.g.
The US goverment require us to keep our tax records,
...but only for four years...
http://www.irs.gov/newsroom/article/0,,id=172250,00.html
http://www.irs.gov/businesses/small/article/0,,id=98513,00.html
Even crimes have a statue of limitations...
http://en.wikipedia.org/wiki/Statue_of_limitations
A misdemeanor will expire in two years...
contracts breaches expire after six years
house roofs are only guarranteed for 15 years...
even CT-Scanners warranties will expire before 10 years.
I would suggest that we define a *time span* for backward compatibility.
Something like:
"ITK CVS will be backward compatible with
versions released in the last *X years*."
At some point we should be able to deprecate old code.
--
Here is our current policy:
http://www.itk.org/Wiki/Proposals:DeprecationProcedure
-----------
Regardless of the philosophical question above,
there are also the following software engineering
practical issues:
A) When the C-Preprocessors becomes CVS
Maintaining a given snapshot of ITK working fine in all
platforms *is already quite a challenge*. Making sure that
a single CVS version can be configured/morphed into behaving
like older versions sounds like an exponential challenge.
Strictly speacking, the only version that is fully backward
compatible with ITK 3.2 is... well: "ITK 3.2".
As the software evolves over time we will end up carring
pallarel versions of CVS copy-pasted into #ifdefs in the
code itself.
As an illustration, let take a look at lines 309 to 333 of
the file
InsightApplications/Auxiliary/VtkFltk/
vtkFlRenderWindowInteractor.cxx
http://www.itk.org/cgi-bin/viewcvs.cgi/Auxiliary/VtkFltk/vtkFlRenderWindowInteractor.cxx?annotate=1.8&root=InsightApplications
--------------------------------------------------
#if ((VTK_MAJOR_VERSION == 4 && VTK_MINOR_VERSION > 0) ||
(VTK_MAJOR_VERSION == 5 && VTK_MINOR_VERSION >= 0))
// new style
this->InvokeEvent(vtkCommand::LeftButtonPressEvent,NULL);
#else
// old style
InteractorStyle->OnLeftButtonDown(Fl::event_state( FL_CTRL ),
Fl::event_state( FL_SHIFT ), Fl::event_x(), this->h()-Fl::event_y()-1);
#endif
break;
case FL_MIDDLE_MOUSE:
#if ((VTK_MAJOR_VERSION == 4 && VTK_MINOR_VERSION > 0) ||
(VTK_MAJOR_VERSION == 5 && VTK_MINOR_VERSION >= 0))
// new style
this->InvokeEvent(vtkCommand::MiddleButtonPressEvent,NULL);
#else
// old style
InteractorStyle->OnMiddleButtonDown(Fl::event_state( FL_CTRL ),
Fl::event_state( FL_SHIFT ), Fl::event_x(), this->h()-Fl::event_y()-1);
#endif
break;
case FL_RIGHT_MOUSE:
#if ((VTK_MAJOR_VERSION == 4 && VTK_MINOR_VERSION > 0) ||
(VTK_MAJOR_VERSION == 5 && VTK_MINOR_VERSION >= 0))
// new style
this->InvokeEvent(vtkCommand::RightButtonPressEvent,NULL);
#else
// old style
InteractorStyle->OnRightButtonDown(Fl::event_state( FL_CTRL ),
Fl::event_state( FL_SHIFT ), Fl::event_x(), this->h()-Fl::event_y()-1);
#endif
--------------------------------------------------
and this only spans two versions of VTK...
Imagine how ITK code will start looking like after 10 releases...
Granted,... this will only concern places in the code where we made
"backaward-incompatible" changes, not to all changes; but still,
keep in mind that we release ITK every three months, therefore by 2009,
we will have about eight different nested blocks of #ifdefs in the code.
It is like replacing CVS version control with an abuse of the
C-preprocessor....
It is not a big deal if we do it for this release and the previous...
but... if we systematically do this, release after release... all
this conditional compilation lines will accumulate in the code.
-------------
A second practical concern is:
B) "If it not tested... it doesn't work"
we will have to figure out a way to test it,
otherwise it is very easy to claim compatibility without
actually having it.
Probably building olders versions of InsightApplications
against the backward compatibility version of the main
ITK library could be a good way to do this.
For example:
Build Against ITK CVS
InsightApplications with CMake variable
with CVS tag backward compatibility
ITK-3-0 3,0
ITK-3-2 3,2
ITK-3-4 3,4
... etc
We could go even further and build the Testing and Examples
directories of old versions of ITK against installed versions
having the backward compatibility flag on for that version number:
For example:
Build ITK Against Insight/Code from CVS
Examples & Testing with CMake variable
with CVS tag backward compatibility
ITK-3-0 3,0
ITK-3-2 3,2
ITK-3-4 3,4
That will give us 81% code coverage on backward compatibility.
(our current code coverage due to Testing and Examples)
Note that we just don't know about the 19% of lines of code
remaining, and we don't really know about behavior itself,
except for the percent of regression tests in the system.
This also raise the question:
How many platforms are we going to test for Backward Compatibility ?
{VS8 ?, gcc 4.2 ?, gcc 3.3 ?, Mac ?, borland ?}
----
Luis
----------------
Brad King wrote:
> Peter Cech wrote:
>
>>Turning off whole class of constructs on compile time works for backward
>>compatibility, but if you develop new code in parallel, concept check at
>>right place might save you a lot of time (been there). What about
>>version-targeted backward compatibility instead?
>>
>>What I mean is enabling backward-compatible or backward-incompatible fix
>>depending on user choice. For the current situation it would look like:
>>
>>- If ITK_3_2_COMPATIBILITY <= VERSION(3,2), a backward compatible bugfix
>> (runtime error reporting) is enabled.
>>
>>- If ITK_3_2_COMPATIBILITY > VERSION(3,2), a backward incompatible
>> bugfix (concept check) is enabled.
>>
>>What do you think about it?
>
>
> Good idea!
>
> This is the approach CMake uses with the "CMAKE_BACKWARDS_COMPATIBILITY"
> variable. It may be set by the user to a value smaller than the current
> version of CMake. Then when a breaking change is made we set things up
> to check the value of this variable. The old behavior is maintained if
> the value of the variable is low enough.
>
> In CMake this variable defaults to the value of the current version for
> a new build tree. Error messages that are related to the breaking
> change include the version number to which CMAKE_BACKWARDS_COMPATIBILITY
> must be set to disable the message. This has the advantage that new
> development and new projects will always get the most modern behavior
> while still allowing existing code to work. Existing build trees
> created by older versions of CMake will already have the variable set to
> the older version in the cache, so users with existing build trees do
> not need to touch anything when they upgrade.
>
> We can probably design a similar solution for ITK. However the trick is
> that the backwards compatibility level required may be different for
> each project using a single ITK build. Perhaps the build of ITK should
> have a CMake option specifying the oldest level of compatibility to
> support (for changes in the compiled binaries). Then a preprocessor
> definition can be used to adjust concept checking rules. Whenever a
> concept check is added it is put inside a compatibility test against the
> current version. A macro can package up the test to make it readable:
>
> #if !ITK_COMPATIBILITY(3, 2)
> // Concept check here...
> #endif
>
> Next we need to find a way to get the compatibility version information
> into the concept check error message. It shouldn't be too hard to
> encode a type describing the version of the check.
>
> -Brad
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
More information about the Insight-developers
mailing list