|
|
| Line 1: |
Line 1: |
| | {{TOC}} | | {{TOC}} |
| − |
| |
| − | This page summarizes the release roadmap for ns-3. A summary of current development activities can be found [[Current Development|here]].
| |
| − |
| |
| − | __FORCETOC__
| |
| − |
| |
| | | | |
| | see the [[Current_Development]] page | | see the [[Current_Development]] page |
| − |
| |
| − | == Release schedule ==
| |
| − |
| |
| − | ns-3 makes regular date-driven (not feature driven) releases, roughly three times per year. ns-3 stable releases are sequentially numbered starting with minor version 1 (for example, ns-3.1 released June 30 2008 was followed by ns-3.2 released September 22, 2008).
| |
| − |
| |
| − | === ns-3.18 ===
| |
| − |
| |
| − | ns-3.17 was released on May 14, 2013. ns-3.18 is scheduled for August 2013. See the [[Ns-3.18]] release page.
| |
| − |
| |
| − | == Release process ==
| |
| − |
| |
| − | ns-3 releases are based on date-driven schedules: rather than target a set of features for a specific version number, we aim instead for a release date and ship whatever is ready by that date. If a cool new feature misses that date, it is not a big deal because the next release is never too far away. The current interval between releases is about 3 months.
| |
| − |
| |
| − | An ns-3 release manager will manage each release. Following ns-3.X release, the release manager is selected for ns-3.X+1. Old ns-3.X release manager is typically responsible for any maintenance releases.
| |
| − |
| |
| − | There are three time windows between releases:
| |
| − | # Open
| |
| − | # Maintenance only (no new features)
| |
| − | # Code freeze (P1 checkins)
| |
| − |
| |
| − | Depending on the proposed next release date, the release manager sets dates
| |
| − | for milestones 2 and 3. The release manager has the authority to slip
| |
| − | the milestone 2, 3, and final release dates.
| |
| − |
| |
| − | 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 [http://code.nsnam.org/ns-3-dev/file/1e8249c58fda/doc/release_steps.txt 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.
| |
