STYLE: Remove legacy content from "itkMultiThreader.h"

[N-Dekker]

"itkMultiThreader.h" was deprecated already from ITK 5.0.

[dzenanz]

@thewtex Is the next version number 5.5, or 6.0?

[dzenanz]

If we begin 6.0 development soon, this entire file should be deleted.

Until then, I would prefer to leave this file as-is.

[N-Dekker]

Of course, this specific code change isn't very important to me. I'm just wondering now what we should do about all the "legacy support code" in general, now that 5.4 is tagged.

Clearly it's OK now to mark things "future legacy":

• pull request FUTURE_LEGACY_REMOVE InternalPixelPointerType, EdgeListPointerType, InputBoundaryConditionPointerType #4554 (merged by Matt after having tagged 5.4 tag)

As well as to move things from "future legacy" to "legacy only":

• pull request PERF: Make ImageRegion trivially copyable (LEGACY_REMOVE) #4691 (also merged by Matt after 5.4)

So then it seems to make sense to me to also drop old "legacy only" things. But again, I'm just wondering 🤷

[dzenanz]

drop old "legacy only" things

This should be done consistently (for all legacy things), once we declare the begin of 6.0 development.

[dzenanz]

Something akin to this: 01580b3.

[N-Dekker]

Thanks @dzenanz Does that mean that all legacy things are treated the same way? Being: let them be there until ITK 6, and then drop them all? (I can imagine that some legacy things are more bothering than others. For example, I would find it a pity if legacy support of #4691 cannot yet be dropped with ITK 6)

[dzenanz]

With a new major version start, we generally remove all the code which is currently legacy, and convert all future legacy into current legacy. Which is what you already did for a few of your favorites 😄

[blowekamp]

Are we going to have some kinds of "ITKv5_COMPATIBILITY" mode?

[dzenanz]

Would we need anything beyond legacy enabled?

[seanm]

Isn't "STYLE" inappropriate? This is a breaking change, not something merely stylistic.

[thewtex]

The next feature release is ITK 6, and it is in progress.

Removing legacy content should be ENH instead of STYLE as @seanm mentioned.

While the process is generally to eventually drop legacy code, we do not need to automatically or always remove "legacy" and update "future legacy" to "legacy". This can be handled on a case-by-case basis. If the code is still widely used, there is not a clear, straightforward path to migration, and the code is not causing issues, it can be kept.

If deprecated code is removed, an entry should be created in an ITK 6 migration guide here: https://github.com/InsightSoftwareConsortium/ITK/tree/master/Documentation/docs/migration_guides

[thewtex]

Clarifications and initialization started in #4696 #4695

[dzenanz]

Time to close this PR and take out the deprecation removal axe? 😄

[dzenanz]

Closing in favor of #4729.