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.
Update: after several release candidates during the month of May (and subsequent bug fixing) the final release target date is June 10, 2010. See Slicer3:3.6_Final_Issues.
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.
- A review meeting will be held on April 29th 2010 at 1249 Boylston st. in Boston
- A release planning meeting will be held 1-3 on Tuesday March 23 at 1249 Boylston in Boston
- 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 sent an email about documentation on 3/24.
- Developers are to ensure that all modules meet the Requirements
- have a test
- have documentation
- have a help section
- have acknowledgments
- Evaluating and prioritizing bug fixes
- Use this mantis filter to see bugs that have been tagged for fixing before 3.6 is release.
- Reviewing dependencies and time schedule
- A 3.6 release in May of 2010 is aggressive, but probably doable.