Roadmap: Difference between revisions

From Nsnam
Jump to navigation Jump to search
 
(28 intermediate revisions by 4 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.8 ===
Besides this, the following [https://www.nsnam.org/about/governance/maintainers/ ns-3 maintainers] announced plans to work on the following topics:


* 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
* Biljana Bojovic from the highest to the lowest priority:
** Reviewing Sionna MR https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2608
** Try to revive NGMN traffic generators MR: https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2245
** Help with other ns-3 MR backlog
** Would like to work also on:
*** the precoding matrix conversion modelling options
*** check if feasible to port some 3GPP models calibration scripts to ns-3


ns-3.7 was released on January 27, 2010.  ns-3.8 will probably occur in April 2010.  See the [[ns-3.8]] release page.
== Long term ==


== Release process ==  
== Historical information ==


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.
see the [[Current_Development]] page for some older Roadmap items (many have been abandoned)
 
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.

Latest revision as of 12:27, 18 March 2026

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

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.

ns-3.48 plans

ns-3.48 is scheduled for May 2026.

The most up-to-date listing of items being worked on in this release cycle can be seen by browsing Merge requests and Issues in the GitLab.com tracker that are tagged with the 'Milestone ns-3.48' tag.

Besides this, the following ns-3 maintainers announced plans to work on the following topics:

Long term

Historical information

see the Current_Development page for some older Roadmap items (many have been abandoned)

Retrieved from "https://www.nsnam.org/mediawiki/index.php?title=Roadmap&oldid=13802"