Difference between revisions of "Roadmap"

From Nsnam
Jump to: navigation, search
(Release schedule)
(Release schedule)
Line 9: Line 9:
 
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).
 
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).
  
=== ns-3.16 ===
+
=== ns-3.17 ===
  
 
ns-3.16 was released on December 21, 2012.  ns-3.17 is scheduled for April 2013.  See the [[Ns-3.17]] release page.
 
ns-3.16 was released on December 21, 2012.  ns-3.17 is scheduled for April 2013.  See the [[Ns-3.17]] release page.

Revision as of 18:35, 13 January 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

This page summarizes the release roadmap for ns-3. A summary of current development activities can be found here.


Release schedule

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).

ns-3.17

ns-3.16 was released on December 21, 2012. ns-3.17 is scheduled for April 2013. See the Ns-3.17 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:

  1. Open
  2. Maintenance only (no new features)
  3. 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 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:

  1. Does not work with all models or on all platforms
  2. Changes existing APIs
  3. 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.