[Insight-developers] Removing method deprecates as of ITK 3.6

Bill Lorensen bill.lorensen at gmail.com
Thu May 1 16:14:54 EDT 2008


I'm still uncomfortable with removing a method once we have released
it. I agree that we should certainly warn if the method is used. But,
if it does not pose a significant maintanence problem, why should we
remove it? Once it's removed, there is no way to notify the user of
the method other than a compilation error. These errors are typically
cryptic.

Here is an excert from out draft backward compatibility policy:
http://insightsoftwareconsortium.org/wiki/images/4/46/APIChangePolicy.pdf

 ..consider your user base. If you have only a dozen highly technical users,
jumping through hoops to maintain backward compatibility may be more trouble
than it's worth. On the other hand, if you have hundreds or thousands of
nontechnical users who cannot deal with manual upgrade steps, you need to
spend a lot of time worrying about those kinds of issues. Otherwise, the first
time you break compatibility you'll easily burn through all the
goodwill you built
up with your users by providing them with a useful program. It's remarkable
how easily people forget the good things from a program as soon as they
encounter the first real problem. From "Preserving Backward Compatibility,
http://www.onlamp.com/lpt/a/5626, Garrett Rooney.


Bill

On Thu, May 1, 2008 at 3:14 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
>  The Wiki page relating to the deprecation policy
>
>       http://www.itk.org/Wiki/ITK_Deprecation_Procedure
>
>  was (conveniently) empty.     :-/
>
>
>
> I'm now adding a first draft.
>
>
> It includes the following basic steps:
>
>  1) Insert itkLegacyMacros()
>  2) Include the Macro-deprecated methods in one official release
>  3) Remove them in the next release.
>
>
> For example,
>
>
>  Class A : method X   is candidate for deprecation
>
>
> Timeline
>
>   June 2012:   Release ITK-9-2
>   July 2012:   Decision to deprecate method A::X()
>   Aug  2012:   Insert itkLegacyMacros around A::X()
>   Sept 2012:   Release ITK-9-4
>   Nov  2012:   Fully remove the method A::X()
>   Dec  2012:   Release ITK-9-6
>
>
> Does this sound reasonable ?
>
>
> In an immediate application of the policy, the ComputeG()
> methods from the KernelTransforms are candidates for being
> removed soon.
>
>
>   Thanks for any suggestions,
>
>
>      Luis
>
>
>
> _______________________________________________
> 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