Difference between revisions of "Slicer3:3.6Release"

From Slicer Wiki
Jump to: navigation, search
Line 34: Line 34:
 
** Ron will be watching...
 
** Ron will be watching...
 
** Developers are to ensure that all modules meet the [[Documentation-3.6#Requirements_for_Modules|Requirements]]
 
** Developers are to ensure that all modules meet the [[Documentation-3.6#Requirements_for_Modules|Requirements]]
 +
*** have a test
 +
*** have documentation
 +
*** have a help section
 +
*** have acknowledgements
 
* Evaluating and prioritizing bug fixes
 
* Evaluating and prioritizing bug fixes
 
* Reviewing dependencies and time schedule
 
* Reviewing dependencies and time schedule

Revision as of 13:01, 24 March 2010

Home < Slicer3:3.6Release

In February 2010 discussions began on the slicer-devel mailing list about a 3.6 release during the spring 2010 timeframe.

* Slicer 3.6 : May 2010 *

This means we would have a feature freeze in April.  Now is the time to 
email the list with any major changes you want to include in this 
release.  Outstanding issues should be entered in the bug tracker.

Considerations on the Schedule

  • We'd like to use a stable version of VTK 5.6 (release branch scheduled to be created in March 2010).
  • Module and slicer core developers will need to update and debug their code during April 2010.
  • The month of May 2010 should be used to address user feedback from the release candidate bugs.

Definition of "Feature Freeze"

During April 2010 the subversion trunk will be in "Feature Freeze" mode - this means that only bug fixes should be checked in (tied to a mantis bug report). Please avoid checking in any new functionality or API changes during this period!

At the end of April we plan to create the Slicer-3-6 release branch in the repository. At this point, new functionality and/or API refactoring can be checked into the trunk.

Why do the "Feature Freeze"? In the past we have found that if the release branch is created while developers are doing a lot of debuggging there is a lot of work required to check the same fix into both the trunk and the release branch. In addition, when API changes occur in the trunk, a fix to the branch often requires porting when merged with the trunk. So the Feature Freeze is a way to avoid unneeded and error prone manual effort.

In late March and during the month of April we will be making beta versions of 3.6 available for testing.

Planning

  • A release planning meeting will be held 1-3 on Tuesday March 23 at 1249 Boylston in Boston

Issues:

  • Establishing documentation requirements for all modules: 3.6 Documentation in Process
    • Modules without good documentation will be removed from the release
    • Nicole will create new documentation template an notify the list
    • Ron will be watching...
    • Developers are to ensure that all modules meet the Requirements
      • have a test
      • have documentation
      • have a help section
      • have acknowledgements
  • Evaluating and prioritizing bug fixes
  • Reviewing dependencies and time schedule

Debugging

Use this mantis filter to see bugs that have been tagged for fixing before 3.6 is release.