ITK 5.0.0, is scheduled for the end of May; tagging is targeted for May 21st.
Feature changes for 5.0.0, which have been reviewed and passed CI tests, can be merged until next Friday, May 17th. Then, only critical bug fixes will be merged. In the meantime, please be extra vigilent to regressions and issues that come up on the the dashboard.
I’d dare to say that the dashboard my need further housekeeping: the configurations that are no longer supported/useful and the sites that apparently lack maintenance (e.g. brian.jouy.inra.fr) could may be removed?
Great! I aim at tagging a new RTK release and submitting a new version of RTK.remote.cmake prior to the release. It seems however that there have been last minute changes that have coloured RTK’s dashboard so I hope this PR will fall in the category of “critical bug fix”, I intend to submit before or on Monday 20.
Does that mean that there is only one day left now to find and fix critical bugs in ITK, before the final release tag of ITK 5.0.0? While the feature freeze only started last Saturday?
I’m very glad to hear that ITK5 is going to be released soon. However, as some fundamental breaking changes were still included with the release candidates (notably the Spatial Object refactoring) and last week streaming redesign, I would prefer a longer feature freeze period. A period to only allow extra testing, critical bug fixes, and documentation, on the ITK master branch.
We are still busy here, trying to make elastix compatible with ITK5. We just got it compiling with a very recent version of ITK from the master, tag 9e12266 of May 9, 2019. But with this ITK version, elastix still has test failures, that need to be solved. And now, with the streaming redesign, elastix does not even compile anymore. Even though we still have ITK_LEGACY_REMOVE=OFF, for elastix.
So we would very much appreciate some more time before the release of ITK5.
No, certainly not: we will find and fix bugs for ITK 5 over the next few months. The next bug fix release, 5.0.1, is scheduled for July. Please make pull requests against the release Git branch for inclusion.
While the Spatial Object refactoring integration ideally would occur earlier, we integrated it as soon as possible and ensured that we had at least a pre-release with it available. In practice, we have to accommodate timing and availability as best as possible.
I am looking forward to elastix on ITK 5! Thank you for pushing that forward. I know it is a significant effort.
Many other projects are waiting for ITK 5.0.0 to be released before they adopt it despite the fact that we had seven pre-releases over the past half year. There were major improvements made to ITK over the past year and a half, pervasive, performant multi-threading, elegant, modern C++, Pythonic interfaces, … These authors of these features should see their work used. Overall, the toolkit truly is in a solid state at this point. The release timing has been announced for many months, and we have the resources to make the release as scheduled. As adoption increases, as with any software, corner cases will reveal bugs and areas that can use refinement. 5.0.1 will come soon enough, and we can declare a moratorium on backwards compatibility for API fixes required for critical issues until 5.1.0.
Hey, this is great news. I haven’t had a chance to look at codebase in a while, went to http://issues.itk.org/ to see what is currently on the go but it gives me a 404. Has the issue tracking moved and is no longer linked there (e.g. as part of git migration)? Or is something else going on?