The next patch (bugfix) release, ITK 5.1.2, is coming up.
Patches currently staged on the Git release branch are:
Bradley Lowekamp (4):
COMP: Updating ITKSimpleITKFilters remote module
BUG: Address divide by zero error in SignedMaurerDistance
STYLE: Improve function types used in SignedMaurerDistanceMap
BUG: Support MRC2014 mode 0 as signed 8-bit integer
Hans Johnson (1):
BUG: itkhdf5 installed paths were incorrect with recent hdf5 versions
Lee Newberg (1):
BUG: MinPriorityQueueElementWrapper constructor needs default constructor
Are there other patches that are missing? Patches should be critical bugfixes, improved support for compilers, and documentation fixes.
I donāt see why not. Please make a PR with it to the release branch. You will probably need to rebase it on release first to avoid pulling many other commits.
By the way I see that there now appear two commits, āBUG: Fix MatrixOffsetTransformBase SetFixedParameters if too few paramsā, at the master branch: 33e9e6b and fcb85b3. How is that possible? They contain exactly the same commit text and code changes. (I just cherry-picked the one from the master branch for the release pull request, without doing any further modification.)
Merge of release branch into master branch discarded any duplicate change sets. I donāt know whether that was done automatically, or conflicts were resolved manually.
OK, thanks, but isnāt is a common scenario that commits from the master branch get cherry-picked into the release?
In general I think an important bug fix may need to be committed directly at the master (in order to make the fix available quickly), as well as at the branch for the next minor release. Right?
Right! The patch is based on the release branch (e.g git checkout -b MyBugFix origin/release). The PR is first made to the master branch, reviewed and merged. Then after it is ensure the nightly dashboard is OK. Another PR can be made to the release branch.
Sometime if other style changes or more than a trivial test is added in āMyBugFixā, Iāll commit them in a second commit on the branch so that the PR for the release branch is as trivial as possible with just the first commit. ( You never know when an apparent trivial change, like to using universal initialization might trigger some compiler issue )
Yes, sure. Slicer currently uses ITK v5.1.1, and it looks there are not a lot of changes in v5.1.2. @jamesobutler you have updated Slicerās ITK a couple of times before, would you be able to test the new ITK version and submit a pull request if if everything looks OK?
Sure. I will probably update ITK to 5.1.2 and also SimpleITK to 2.0.1. Just need to make sure I use an appropriate SimpleITKFilters tag with latest changes.
To explain further ā a Git commit hash is based on the content of the files that are changed and the commit message, but also other information like the parent commit. So, we have to keep the same parent commit to keep the same hash (commit identifier).
)