Difference between revisions of "Roadmap"

From Nsnam
Jump to: navigation, search
(ns-3.6)
(complete the previous edit)
 
(30 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.6 ===
+
 
+
ns-3.5 was released on July 3, 2009.  ns-3.6 will probably occur around September or October.  This page will be updated soon with a list of potential merge items.
+
 
+
Features already added in this release cycle:
+
* [http://groups.google.com/group/ns-3-reviews/browse_thread/thread/e51ba9aea3d81478# Multiple frequency channels in WiFi]
+
 
+
Features planned (see our [[Current Development]] page:
+
* Underwater Acoustic Device model
+
* 802.11s mesh model
+
* 802.11 10 MHz channels
+
* others TBD
+
 
+
== 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.
+

Latest revision as of 21:25, 20 October 2013

Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects

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

see the Current_Development page