ITK/Release Schedule: Difference between revisions

From KitwarePublic
< ITK
Jump to navigationJump to search
m (→‎For All: Add an e.g. for the regression test name)
No edit summary
Line 1: Line 1:
The next feature release is 4.9 scheduled for December, 2015.
The next feature release is 4.11 scheduled for December, 2016.


== Release Life Cycle ==
== Release Life Cycle ==
Line 30: Line 30:
* Tarballs are linked from the ITK Download Page
* Tarballs are linked from the ITK Download Page


== Release 4.10 Schedule ==
== Release 4.11 Schedule ==


{| border="1"
{| border="1"
Line 36: Line 36:
! Release Number !!  Date  
! Release Number !!  Date  
|-
|-
| RC Cycles|| May 9th, 2016
| RC Cycles|| November 28th, 2016
|-
|-
| Final Release || May 24th, 2016
| Final Release || December 15th, 2016
|}
|}


== Release 4.11 Schedule ==
== Release 4.12 Schedule ==


{| border="1"
{| border="1"
Line 47: Line 47:
! Release Number !!  Date  
! Release Number !!  Date  
|-
|-
| RC Cycles|| November 28th, 2016
| RC Cycles|| May 9th, 2016
|-
|-
| Final Release || December 15th, 2016
| Final Release || May 24th, 2016
|}
|}



Revision as of 17:14, 26 May 2016

The next feature release is 4.11 scheduled for December, 2016.

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 November 28th, 2016
Final Release December 15th, 2016

Release 4.12 Schedule

Release Number Date
RC Cycles May 9th, 2016
Final Release May 24th, 2016


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 versions 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 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