Create branch release-4.10

[jcfr]

To support VTK >= 8.90, we will have to apply specific changes.

Considering the current rate of fixes integrated in this project (few commits per year), I don't think it makes sense to increase the complexity of the code base to support building against both Slicer + VTK 8.2 and Slicer + VTK >= 8.90.

For this reason, I suggest to:

• create a branch called release-4.10 (similar to the existing release-4.8) and
• update https://github.com/Slicer/ExtensionsIndex/blob/4.10/UKFTractography.s4ext#L11 to reference release-4.10 instead of master

[jcfr]

cc: @tashrifbillah @pieper

[tashrifbillah]

Are you aware that we use VTK 7?

---

similar to the existing release-4.8

We don't have any release from GitHub yet. Where do you get that?

[jcfr]

Are you aware that we use VTK 7?

This version of VTK is used only when building the project standalone and not when building as an extension.

Few questions:

• Does it make sense to continue maintain the standalone version of this tool ?
  • If yes, is there resources to setup continuous integration and releases of the tool ?
• Should it be only distributed as a Slicer modules ?

We don't have any release from GitHub yet. Where do you get that?

See https://github.com/pnlbwh/ukftractography/tree/release-4.8

This is a convenient branch that was used to build the extension against Slicer 4.8 while allowing ukftractography master branch to diverge

[tashrifbillah]

Few questions

We shall continue to maintain the standalone version but we may not be able to set up CI as of now.

[tashrifbillah]

Would you like the branch release-4.10 to be made after merging PR #133 ?

[tashrifbillah]

This version of VTK is used only when building the project standalone

Have you tested building the project standalone after affecting your proposed change? If yes, in which platforms and do they include CentOS 7?

[tashrifbillah]

Waiting on my question ...

[jcfr]

Have you tested building the project standalone after affecting your proposed change?

No.

And it turns out that I will not have the bandwidth to do before Oct 12th

Considering that the standalone version of the project is relying on now obsolete dependency, I suggest to update the dependencies:

• VTK7 -> VTK9
• ITK 4,11 to ITK 5.1
• ...

The migration guides available here may be helpful. See https://www.slicer.org/wiki/Documentation/Nightly/Developers/Tutorials/MigrationGuide

If you can tackle this, I could review pull requests.

If yes, in which platforms and do they include CentOS 7?

We use Centos7 to build the Slicer linux package to ensure it will run a broad set of linux distribution. It is inspired from what is done for python wheels. See https://www.python.org/dev/peps/pep-0571/

[tashrifbillah]

Shall I make release-4.10 branch from the current master now?

[tashrifbillah]

Ping @jcfr

[pieper]

@tashrifbillah we use the release-X.Y branch name convention to indicate which version of the code should be used to generate Slicer extensions. Currently, Slicer's stable is 4.11.20200930, so we want to use a release-4.11 branch of the extensions that will be kept as the corresponding stable version of the extension (see Slicer/ExtensionsIndex#1743).

At the same time, the Slicer nightly version is being upgraded to vtk9, and that may have ripple effects on the various extensions that we can fix in the master branches of the extensions. These will be the ones that correspond to the master branch of Slicer and are linked by the scmrevision field of the s4ext file that is in the master branch of the extension index. The vtk9 version will eventually become Slicer-5.0 when it is released.

The master branch of the ukf repository can also be used to build outside of Slicer if that works. Ideally we only need one or maybe two dedicated branches to handle these transitions, but sometimes branches are easier than ifdefs and cmake flags to manage the differences.

[tashrifbillah]

Thank you @pieper , created https://github.com/pnlbwh/ukftractography/tree/release-4.11