Roadmap: Difference between revisions

From Nsnam
Jump to navigation Jump to search
(move content from Roadmap to Current Development)
(complete the previous edit)
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]].
__FORCETOC__


see the [[Current_Development]] page
see the [[Current_Development]] page
== 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.18 ===
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.

Revision as of 21:25, 20 October 2013

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

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

see the Current_Development page

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