|
|
(35 intermediate revisions by 3 users not shown) |
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]].
| + | see the [[Current_Development]] page |
− | | + | |
− | __FORCETOC__
| + | |
− | | + | |
− | == Release schedule ==
| + | |
− | | + | |
− | ns-3 plans regular date-driven (not feature driven) releases. 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.5 ===
| + | |
− | | + | |
− | ns-3.5 should be in the June/July 2009 timeframe. Feel free to suggest features that may be mergeable in the May 2009 timeframe.
| + | |
− | | + | |
− | These features are already merged:
| + | |
− | * 802.11e EDCA support: Has been added possibilty to manage QoS traffic on wifi stations.
| + | |
− | * 802.11n initial support: Has been added support for A-MSDU frame aggregation feature.
| + | |
− | | + | |
− | These features are scheduled:
| + | |
− | * [http://www.nsnam.org/wiki/index.php/Current_Development#Ipv4_API.2C_routing.2C_cleanup IPv4 Routing Refactoring;]
| + | |
− | * Additional IPv6 Support
| + | |
− | | + | |
− | == 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.
| + | |