Difference between revisions of "ITK/Release Schedule"
< ITKJump to navigationJump to search
(update top of page to be consistent with new dates in the table)
|Line 1:||Line 1:|
The next feature release is 4.11 scheduled for
The next feature release is 4.11 scheduled for , .
== Release Life Cycle ==
== Release Life Cycle ==
Revision as of 11:16, 9 January 2017
The next feature release is 4.11 scheduled for January, 2017.
Release Life Cycle
Last period for adding classes and features
- New classes will be selected from good reviews from the Insight Journal
- New features and new methods can be added during this period.
- Increase code coverage
- address any UNTESTED files
- address files with code coverage lower than 80%
- Address Run-time memory issues
- Purify reports
- Valgrind reports
- No new features should merged during the feature freeze, i.e. ENH: commits, although they can be prepared in Gerrit.
- Release candidates (RC's) will be tagged weekly.
- RC's will be tagged after dashboard examination and discussion at the Friday TCon.
- The repository will be hard frozen to only allow merging by gatekeepers on Wednesday evening before the dashboards start. The freeze will be released after tagging.
- For the final RC, only gatekeeper merges will occur.
- Tarballs are posted to SourceForge
- Tarballs are linked from the ITK Download Page
Release 4.11 Schedule
|RC Cycles||January 9th, 2017|
|Final Release||January 23rd, 2017|
Release 4.12 Schedule
|RC Cycles||May 9th, 2017|
|Final Release||May 24th, 2017|
Check-list for Moving Code from IJ to Gerrit and from Gerrit
For IJ Articles To Gerrit
- Responsible developer should add a review before moving into local copy of Gerrit. Please provide authors with feedback regarding changes that were made to conform to ITK style/documentation etc.
For Adding Images to Input or Baseline
- Images should be SMALL.
- The source tree is not an image database, but a source code repository.
- Adding an image larger than 50Kb should be justified by a discussion in the Developers list
- Regression images should not use Analyze format unless the test is for the AnalyzeImageIO and related classes.
- Images should use non-trivial Metadata.
- Origin should be different form zeros
- Spacing should be different from ones, and it should be anisotropic
- Direction should be different from Identity
For Moving Code From Review
- At least one independent (other than contributor) should sign off on the API
- Coverage should be as close to 100% as possible.
- and never lower than 90%.
- For example, itkTransformIOBase.cxx is only at 63% coverage. Should be easily fixed by adding a Print() to one of the tests.
- Check all comments for proper English
- Should pass KWStyle. IJ articles should be checked with KWStyle before checking into repository.
- Should pass PrintSelf. IJ articles should pass PrintSelf check before checking into repository.
- Replace itkGetMacro with itkGetConstMacro.
- Header file should contain Insight Journal citation
- Using the "handle" link.
- Progress should be present for all filters. Use itk::SimplerFilterWatcher to exercise progress and PrintSelfs.
- When appropriate, class should handle image directions. Tests should use non-default values for origin, spacing and dimension.
- GaborImageSource did not provide methods to set/get directions.
- Regression tests' names should, when possible, have the same name as the class tested (plus the Test keyword: e.g. itkGaborKernelFunctionTest.cxx).
- Exceptions should be descriptive and provide as much information as possible
- Member data should be private with access if required through Get methods.