|
|
| (7 intermediate revisions by the same user 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 == |
|
| |
|
| == Development priorities ==
| | ns-3.48 is scheduled for May 2026. |
|
| |
|
| In 2013, the project is focusing on the following initiatives:
| | 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. |
|
| |
|
| # [[BakeIntegration|modular build system]]
| | Besides this, the following [https://www.nsnam.org/about/governance/maintainers/ ns-3 maintainers] announced plans to work on the following topics: |
| # [[Object_Start_Stop_Specification|starting and stopping of objects]]
| |
| # merge of the [[Direct_Code_Execution_status|Direct Code Execution]] framework
| |
| # [[Data_Collection_Framework|data collection]] and [[NSF_Frameworks|experiment control]] frameworks
| |
|
| |
|
| There are also a number of development efforts with the individual models; please check the [[Current_Development|Current Development]] page for a general categorization of activities, and the current release page (see below) for the current release activities.
| | * 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 |
|
| |
|
| == Release schedule == | | == Long term == |
|
| |
|
| 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).
| | == Historical information == |
|
| |
|
| === ns-3.18 ===
| | see the [[Current_Development]] page for some older Roadmap items (many have been abandoned) |
| | |
| 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.
| |