ITK/Release Schedule: Difference between revisions
From KitwarePublic
< ITK
Jump to navigationJump to search
m (bug: 2013 -> 2014) |
Jhlegarreta (talk | contribs) m (→RC process: Minor ortography correction) |
||
Line 19: | Line 19: | ||
=== RC process === | === RC process === | ||
* No new features should merged during the feature freeze, i.e. ''ENH:'' commits, although they can be | * 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. | * Release candidates (RC's) will be tagged weekly. | ||
* RC's will be tagged after dashboard examination and discussion at the Friday TCon. | * RC's will be tagged after dashboard examination and discussion at the Friday TCon. |
Revision as of 06:25, 4 June 2014
The next feature release is 4.6 scheduled for June, 2014.
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
Release 4.6 Schedule
Release Number | Date |
---|---|
RC Cycles | June 9, 2014 |
Final Release | June 30, 2014 |
Release 4.7 Schedule
Release Number | Date |
---|---|
RC Cycles | November 28, 2014 |
Final Release | December 15, 2014 |
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.
- Use vcl verions of all transcendental functions.
- For example, itkGaborKernelFunction used sin() and cos() rather than vcl_sin() and vcl_cos().
- 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 test.
- Exceptions should be descriptive and provide as much information as possible
- Member data should be private with access if required through Get methods.