|
|
| (31 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]].
| | ns-3 is a community-driven project, and as such, we cannot typically make guarantees about the availability of new or improved code; our maintainers work largely on a best-effort basis. However, we use this page to describe our goals (time-permitting) for each release, and where we broadly are trying to steer the project for the future. |
|
| |
|
| __FORCETOC__
| | == ns-3.48 plans == |
|
| |
|
| == Release schedule ==
| | ns-3.48 is scheduled for May 2026. |
|
| |
|
| ns-3 makes regular date-driven (not feature driven) releases, roughly quarterly. 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). | | The most up-to-date listing of items being worked on in this release cycle can be seen by browsing [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests?scope=all&state=opened&milestone_title=ns-3.48 Merge requests] and [https://gitlab.com/nsnam/ns-3-dev/-/issues?scope=all&state=opened&milestone_title=ns-3.48 Issues] in the GitLab.com tracker that are tagged with the 'Milestone ns-3.48' tag. |
|
| |
|
| === ns-3.6 ===
| | Besides this, the following [https://www.nsnam.org/about/governance/maintainers/ ns-3 maintainers] announced plans to work on the following topics: |
|
| |
|
| ns-3.5 was released on July 4, 2009. ns-3.6 will probably occur in early October. See the [[ns-3.6]] release page. | | * Tom Henderson is prioritizing: |
| | ** Supporting wifi (and eventual ns-3-dev) transition to strongly-typed quantities and units |
| | ** Merging GSoC 2025 code [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2571 Orbital NTN] and [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2482 6LoWPAN ND] |
| | ** Seeing if we can revive [https://github.com/direct-code-execution/ns-3-dce/pull/147 ns-3 DCE] |
| | ** Working on issue and MR backlog |
|
| |
|
| '''Features already added''' in this release cycle:
| | == Long term == |
| * [http://groups.google.com/group/ns-3-reviews/browse_thread/thread/e51ba9aea3d81478# Multiple frequency channels in WiFi]
| |
| * IPv6 models
| |
| ** IPv6 interface, IPv6 layer, IPv6 raw socket, Static IPv6 routing, ICMPv6 layer, Some ICMPv6 error messages (destination unreachable, ...), Neighbor Discovery Protocol (NS/NA, RS/RA, redirection), Ping6 application (send Echo request), Radvd application (send RA), Examples (ping6, simple-routing-ping6, radvd, radvd-two-prefix, icmpv6-redirect).
| |
| * AthStats Wifi trace sink (trace sink to provide output similar to Madwifi's athstats command)
| |
| * [http://linuxwireless.org/en/developers/Documentation/mac80211/RateControl/minstrel Minstrel rate control] for WiFi
| |
|
| |
|
| '''Features planned''' (see our [[Current Development]] page:
| | == Historical information == |
| * Underwater Acoustic Device model
| |
| * 802.11s mesh model
| |
| * 802.11 10 MHz channels
| |
| * WiMax
| |
|
| |
|
| == Release process ==
| | see the [[Current_Development]] page for some older Roadmap items (many have been abandoned) |
| | |
| 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.
| |