ITK/Release Schedule: Difference between revisions

From KitwarePublic
< ITK
Jump to navigationJump to search
m (bug: 2013 -> 2014)
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 preparred in Gerrit.
* 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.

Release History