Ns-3.3
Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects
Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers
This page summarizes the release planning for ns-3.3.
The Release Manager
Craig Dowell (craigo at ee.washington.edu) is the release manager for ns-3.3 and is the contact for any release issues.
ns-3.3 is scheduled for release in December 15, 2008.
The ns-3.3 Release Schedule
ns-3 releases are based on date-driven schedules as opposed to feature-driven schedules. We decide on a release date and then the release manager works backward to define windows during which time certain activites related to the release can happen. This has been done for ns-3.3 and the important milestones are:
M# September 22 &mdash ns-3.2 posted; M# September 22 &mdash ns-3.3 Open period begins; M# October 20 &mdash Recommended cutoff for new feature submission; M# October 27 &mdash Deadline for new feature submissions that require design review; M# November 3 &mdash Approved new feature ready-for-merge deadline; M# November 3 &mdash Late merge period begins; M# November 10 &mdash Late merge period ends; M# November 10 &mdash Open period ends; M# November 10 &mdash Maintenance period begins; M# December 1 &mdash Maintenance period ends; M# December 1 &mdash Code freeze begins; M# December 1 &mdash ns-3.3-RC1; M# December 4 &mdash ns-3.3-RC2; M# December 8 &mdash ns-3.3-RC3; M# December 11 &mdash ns-3.3-RC4; M# December 15 &mdash ns-3.3 posted M# December 15 &mdash ns-3.4 Open period begins.
In "Open" phase, the release manager has a low profile. However, the release manager should be involved with scheduling and approving major merges, because he or she may want to manage the dependencies and do some testing in a particular order. In open phase, modules that are self contained (e.g. a new channel model for WiFi) don't really need much coordination with the release manager.
(See below for "major merges").
In "Maintenance" phase, no new features are to be added, but the maintainers may check in fixes to bugs. Maintainers may appeal to the release manager for adding new self-contained features, but it is release manager's call.
In Code freeze phase, the release manager must approve (or apply) all changes to ns-3-dev outside of documentation. The release manager may also set a freeze date on documentation.
Typically, the feature freeze is 4-6 weeks before the projected release date, and the code freeze is 2 weeks before the projected release date.
The release manager is responsible for preparing and maintaining RELEASE_NOTES, changes.html, and release candidates, and for updating web pages and wikis concerning release-specific information (e.g., update the Installation wiki page if there is an issue discovered with a compiler).
Detailed steps for doing the source code release are found in the doc/release_steps.txt file in the ns-3-dev repository.
Major merges
Major merges are those that are not self contained within the scope of a single maintainer, those that change API, and those that have some issues with the build system or other dependencies.
Past examples of major merges:
- NSC
- Bridge device and promiscuous mode
- Attribute system
- Python bindings
If a proposed new feature (or refactoring) meets one of these criteria:
- Does not work with all models or on all platforms
- Changes existing APIs
- Crosses maintainer boundaries
then, the release manager will ask for code review by all maintainers and request a positive ack that the maintainer is comfortable with the proposed merge and believes that it will interact well with, or have no effect on, his or her component. This code review process will typically lead to questions and comments that need resolution.
In the case where a new model does not work with the existing simulator, (not on all platforms, not with all existing models) then the model must receive an approval (exception) from the architecture board or project lead. Typically, they will either grant this exception or ask the model author to improve the support and come back later.
The release manager can veto a major merge based on preliminary testing or concern about looming problems to finalize things for the release.
Finally, it is good practice to coordinate among the active committers and release manager when you are doing a major merge, to avoid bad merge collisions.
