ITK/Release Schedule: Difference between revisions

From KitwarePublic
< ITK
Jump to navigationJump to search
Line 36: Line 36:
! Release Number !! Start Date !! End Date
! Release Number !! Start Date !! End Date
|-
|-
| RC Cycles || September 7 2012 || September 17 2012
| RC 1 || November 26 2012 || November 30 2012
|-
|-
| Testing tarballs || unscheduled || unscheduled
| RC 2 || December 3 2012 || December 7 2012
|-
|-
| Posting tarballs || unscheduled || unscheduled
| RC 3 || December 10 2012 || December 14 2012
|-
| Final Release || December 17 2012 || Party!
|}
|}



Revision as of 17:07, 5 November 2012

The next release is 4.3 scheduled for September 15th, 2012.

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 preparred 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.3 Schedule

Release Number Start Date End Date
RC 1 November 26 2012 November 30 2012
RC 2 December 3 2012 December 7 2012
RC 3 December 10 2012 December 14 2012
Final Release December 17 2012 Party!

Release 4.4 Schedule

Release Number Start Date End Date
RC Cycles December 14 2012 December 17 2012

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.
  • 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.

Release History