Difference between revisions of "ITK/Release Schedule"

From KitwarePublic
< ITK
Jump to navigationJump to search
(update top of page to be consistent with new dates in the table)
Line 1: Line 1:
The next feature release is 4.11 scheduled for December, 2016.
The next feature release is 4.11 scheduled for January, 2017.


== Release Life Cycle ==
== Release Life Cycle ==

Revision as of 11:16, 9 January 2017

The next feature release is 4.11 scheduled for January, 2017.

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 January 9th, 2017
Final Release January 23rd, 2017

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.

Release Changelogs

Release Changelogs