ITK/Release Schedule: Difference between revisions
From KitwarePublic
< ITK
Jump to navigationJump to search
Line 26: | Line 26: | ||
* Tarballs are linked from the ITK Download | * Tarballs are linked from the ITK Download | ||
== Release 3. | == Release 3.20 Schedule == | ||
{| border="1" | {| border="1" | ||
Line 32: | Line 32: | ||
! Release Number !! Start Date !! End Date | ! Release Number !! Start Date !! End Date | ||
|- | |- | ||
| | | Bug triage || May 1 2010 || May 5 2010 | ||
|- | |- | ||
| | | CVS Tagging || July 14 2010 || July 14, 2010 | ||
|- | |- | ||
| | | Testing tarballs || July 15 2010 || July 15 2010 | ||
|- | |- | ||
| Posting tarballs || July 15 2010 || July 15 2010 | |||
| Posting tarballs || | |||
|} | |} | ||
=== | === Code Coverage Campaign === | ||
=== Valgrind Hunting Campaign === | |||
== Check-list for Moving Code from IJ to Review and from Review == | == Check-list for Moving Code from IJ to Review and from Review == |
Revision as of 22:27, 25 April 2010
The next release is 3.18 scheduled for Jan 6 2010.
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
CVS Tagging
The repository is tagged by using two tags, one for the reference, and another for the branch.
Posting Tarballs
- Tarballs are posted to SourceForge
- Tarballs are linked from the ITK Download
Release 3.20 Schedule
Release Number | Start Date | End Date |
---|---|---|
Bug triage | May 1 2010 | May 5 2010 |
CVS Tagging | July 14 2010 | July 14, 2010 |
Testing tarballs | July 15 2010 | July 15 2010 |
Posting tarballs | July 15 2010 | July 15 2010 |
Code Coverage Campaign
Valgrind Hunting Campaign
Check-list for Moving Code from IJ to Review and from Review
For IJ Articles To Review
- Responsible developer should add a review before moving into local copy of Review. 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
- Make sure that you use the "cvs add -kb" option when adding binary files to the CVS repository.
- 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.
- ITK_EXPORT should appear in each class definition. This triggers the PrintSelf checker.
- 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.