Gearing up for ITK5

After a prolonged discussion over the years, and following the recent discussion, during confab meeting on December 8th, we (@matt.mccormick @fbudin @blowekamp @hjmjohnson and @dzenanz) agreed that the time is right to start ITK5 development after version 4.13 is released!

The rest of this post explains the plan. These changes are anticipated after ITK 4.13 is released, which is scheduled for December 18th. Your participation is encouraged! We will be stretching current resources to reach these goals, but most of these objectives should be ready for the June 2018 release. Other contributions are welcome.

The main point is finally allowing C++11 code into ITK. C++11 makes it easier to write new code, it has many features which greatly help heavily-templated libraries such as ITK, and has expanded standard library.

The most visible side effect will be dropping support for older compilers. In the future, ITK will be dropping compiler support more quickly, in line with vendor support for compilers being shorter nowdays. The plan is to not support a compiler for longer than its vendor supports it. Concrete versions are not decided yet, but current draft of minimum versions are Visual Studio 2013, GCC 4.8 (which came with Ubuntu 14.04) and clang 3.3 (which came with Xcode 5 and OS X 10.9 Mavericks). As VS13’s support for C+11 is patchy, it is the most likely to be dropped next (with ITK 5.1 or a later release), assuming we even support it in ITK 5.0.

A notable side-effect of dropping compiler support, will be dropping Python 2 support on Windows (which uses Visual Studio 2008 for its binaries). Python 2 will continue to be supported on other operating systems, as well as Python 3 (3.5 and newer) on all OSes.

Also important is a move to much newer CMake - version 3.8.2 or the one in upcoming Ubuntu 18.04 LTS (whichever is newer). This will allow us to gradually improve and simplify ITK’s build system without breaking backwards compatibility. In the short term this will likely force many Linux developers to either use a newer OS, or install a newer version of CMake themselves.

Another planned change is a move to GitHub. As many people are familiar with development process on GitHub, and most already have a GitHub account, contributing to ITK will be easier. We expect greater participation of the community due to this.

This is a great opportunity for some backwards incompatible threading improvements (including changes to API), to increase performance in the default configuration.

We will go through a cycle of code removal and deprecation. We will remove deprecated code (methods and classes) as well as v3 compatibility modules and macros. Code and interfaces currently marked as future deprecated might become deprecated instead of being outright removed.

Some modules have not been used or maintained in a very long time (e.g. ITKNeuralNetworks, ITKBioCell). Some others are used infrequently, while making a significant contribution to ITK’s build time (e.g. ITKFEM). We plan to port them and perhaps some other modules to remote modules and turn them off by default. We need feedback about which modules should be removed, which made remote, and which only turned off by default. Please nominate additional modules for cleanup.

We plan to postpone the biggest changes for a few months, to allow easier back-porting of bugs to patch releases of ITK 4 (e.g. 4.13.1, 4.13.2). But ITK 4 will not be supported after ITK 5 has been released. We will accept bug fix patches to v4 release branch, but features will not be back-ported.

Finally, we anticipate quicker increases in ITK’s major version numbers in the future, as we will want to switch to C++14 in a not too distant future, and to C++17 a year or two after that. Exciting times ahead!

7 Likes