ITK/Backward Compatibility Open Discussion: Difference between revisions
From KitwarePublic
< ITK
Jump to navigationJump to search
| Line 28: | Line 28: | ||
== Topic C == | == Topic C == | ||
= Position Statement 2 = | = Position Statement 2 (Bill Lorensen) = | ||
== Topic A == | == Topic A == | ||
== Topic B == | == Topic B == | ||
== Topic C == | == Topic C == | ||
= Position Statement 3 = | = Position Statement 3 = | ||
Revision as of 05:29, 6 May 2008
The topic of backward compatibility has generated animated discussions among users and developers.
We gather here multiple points of view from some of the influential users and developers.
The content of this page is not intended to be conclusive on any of the proposed topics. It simple intends to gather elements of discussion that will serve as food-for-thought.
Main Discussion Topics
Discussion Topics
- Deprecation of classes / method. When to deprecate, and how to deprecate.
- Drawing the line where fixing a bug will result in backward compatibility breaks.
- Cathedral/Bazar: How much burden to put on new contributions to the toolkit.
- Is the Insight Journal + Code Review directory a process that is too burdensome.
- When can we require additional effort from users to update their code for using new versions of ITK ?
- Never
- Once a year
- Once every five years
- How far back in time should we maintain backward compatibility (relates to the previous topic)
- Today's version should be compatible with ITK version from N years ago
- 1 year ?
- 2 years ?
- 5 years ?
- Today's version should be compatible with ITK version from N years ago
