STYLE: Remove legacy content from "itkMultiThreader.h"#4693
STYLE: Remove legacy content from "itkMultiThreader.h"#4693N-Dekker wants to merge 1 commit intoInsightSoftwareConsortium:masterfrom
Conversation
"itkMultiThreader.h" was deprecated already from ITK 5.0.
github-actions
bot
added
the
type:Style
|
@thewtex Is the next version number 5.5, or 6.0? |
dzenanz
left a comment
dzenanz
left a comment
There was a problem hiding this comment.
If we begin 6.0 development soon, this entire file should be deleted.
Until then, I would prefer to leave this file as-is.
|
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":
As well as to move things from "future legacy" to "legacy only":
So then it seems to make sense to me to also drop old "legacy only" things. But again, I'm just wondering 🤷 |
This should be done consistently (for all legacy things), once we declare the begin of 6.0 development. |
|
Something akin to this: 01580b3. |
|
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) |
|
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 😄 |
|
Are we going to have some kinds of "ITKv5_COMPATIBILITY" mode? |
|
Would we need anything beyond legacy enabled? |
|
Isn't "STYLE" inappropriate? This is a breaking change, not something merely stylistic. |
|
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 |
|
Time to close this PR and take out the deprecation removal axe? 😄 |
|
Closing in favor of #4729. |
5 participants
"itkMultiThreader.h" was deprecated already from ITK 5.0.