ITK/Release Schedule: Difference between revisions
From KitwarePublic
< ITK
Jump to navigationJump to search
Line 82: | Line 82: | ||
* Header file should contain Insight Journal citation | * Header file should contain Insight Journal citation | ||
** Using the "handle" link. | ** Using the "handle" link. | ||
* Progress should be present for all filters. Use itk::SimplerFilterWatcher to exercise progress and PrintSelfs. | * 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. | * When appropriate, class should handle image directions. Tests should use non-default values for origin, spacing and dimension. |
Revision as of 17:45, 27 May 2016
The next feature release is 4.11 scheduled for December, 2016.
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.
Feature Freeze
- Increase code coverage
- address any UNTESTED files
- address files with code coverage lower than 80%
- Address Run-time memory issues
- Purify reports
- Valgrind reports
RC process
- 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.
Posting Tarballs
- Tarballs are posted to SourceForge
- Tarballs are linked from the ITK Download Page
Release 4.11 Schedule
Release Number | Date |
---|---|
RC Cycles | November 28th, 2016 |
Final Release | December 15th, 2016 |
Release 4.12 Schedule
Release Number | Date |
---|---|
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.
For All
- 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.