DOC: Clarify further remote module version bumps with ITK minor releases

[jhlegarreta]

Clarify further remote module major version bumps with ITK minor releases.

PR Checklist

• No API changes were made (or the changes have been approved)
• No [major design changes]

[jhlegarreta]

@SimonRit following the thread in PR #4765 and Matt's clarification.

[blowekamp]

Why is this preferred over more specific pinning of the package install requirements to something like "itk~=5.4.0"?

[SimonRit]

Thanks for integrating Matt's comment to the documentation. I still don't really understand why the major version of the remote module should be bumped but not the major version of ITK but this is most likely due to a lack of knowledge on my side.

[blowekamp]

My suspicion is that this line is not correct:
https://github.com/InsightSoftwareConsortium/ITKIsotropicWavelets/blob/master/setup.py#L57

and should be something like "itk~=5.4.0" to only allow the ITK patch version to very.

[jhlegarreta]

My suspicion is that this line is not correct:
https://github.com/InsightSoftwareConsortium/ITKIsotropicWavelets/blob/master/setup.py#L57
and should be something like "itk~=5.4.0" to only allow the ITK patch version to very.

InsightSoftwareConsortium/ITKIsotropicWavelets#159 and #4748 (comment).

[blowekamp]

So, While ITK's main Python packages do not follow semantic versioning, it is recommended that remote module bump the major version when the minor version of ITK change to follow semantic versioning best practices.

Is that clearer?

[thewtex]

Perhaps it is clearer to have remote module package versions follow their own semantic versioning path, i.e. bump the minor version when bumping the itk version they build against ?. However, have the dependency on itk-X.X.* indicate the ABI compatibility in this explanation.

[SimonRit]

Perhaps it is clearer to have remote module package versions follow their own semantic versioning path, i.e. bump the minor version when bumping the itk version they build against ?. However, have the dependency on itk-X.X.* indicate the ABI compatibility in this explanation.

This has my preference but it might be because I didn't get the explanation...

[thewtex]

I initially thought a remote module update should be considered a breaking change because it forces an itk version update, but this seems too stringent.

[thewtex]

Does everyone agree ( 👍 👎 )that we should recommend bumping the minor version on remote module packages with a new itk major or minor release?

[jhlegarreta]

Folks, please, go ahead and edit the change and push force so that it reflects better what the policy should be so that the policy and the underlying rationale are clear onwards.

[jhlegarreta]

The below will need to be changed in accordance to what is adopted here:
https://github.com/InsightSoftwareConsortium/ITK/blob/master/Utilities/Maintenance/UpdateRequiredITKVersionInRemoteModules.sh#L26-L27

as well as the logic in the script.