From Nsnam
Revision as of 09:23, 16 November 2009 by Fmoatamr (Talk | contribs)

Jump to: navigation, search

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 ongoing release planning for ns-3.7. The release manager is Faker Moatamri.

Tentative ns-3.7 Release Schedule

  1. October 21 -- ns-3.6 posted;
  2. October 21 -- ns-3.7 Open phase begins;
  3. November 18 -- Deadline for new feature merge;
  4. November 18 -- Begin the phase of small feature development and bug fixing;
  5. December 16 -- Small feature development and bug fixing ends;
  6. December 16 -- Open phase ends;
  7. December 16 -- Maintenance phase begins;>
  8. January 6 -- Maintenance phase ends;
  9. January 6 -- Code freeze phase begins;
  10. January 6 -- ns-3.7-RC1;
  11. January 8 -- ns-3.7-RC2;
  12. January 12 -- ns-3.7-RC3;
  13. January 15 -- ns-3.7-RC4;
  14. January 20 -- ns-3.7 posted;
  15. January 20 -- Code freeze phase ends;
  16. January 20 -- ns-3.8 Open phase begins.

As described in the Roadmap there are three broad sections in the release schedule. During the open phase, people wanting to include a new feature in ns-3.7 should contact Faker and arrange to have their features merged into ns-3-dev. You will be expected to provide the following:

  • A mercurial patch, bundle or repo against the current version of ns-3-dev that contains your proposed feature addition. You need to make sure that we can apply this patch and build and run (debug and optimized as appropriate) all unit and regression tests sucessfully on all of our target machines;
  • A summary of the additions you are proposing and an explanation of any changes to existing code that had to be done in order to support your feature (this will be used to genenerate release notes and will be provided to maintainers if a code review is indicated);
  • Some kind of unit or system test that can be used to determine if your feature is actually working at each stage of the integration.

One of us will take a quick look at your proposed addition and determine if a code review is required. According to the book of instructions a code review requiring positive acknowledgement by maintainers is indicated if:

  • Your proposed feature does not work with all models or on all platforms;
  • Your feature changes pre-existing APIs;
  • Your feature crosses maintainer boundaries.

Just to be safe, we will probably run a feature submission by at least one maintainer according to the general area of applicability of the feature. For example, if you submit an entirely new device driver model, as a courtesy we will run this submission by the maintainers of the current devices. The maintainers won't have any responsibility to positively ack the submission, but we will take some time to allow a reasonable review.

We will coordinate new feature merges beginning at the start of the late merge period (December 9, 2009). This is the time during which we merge the code from all of those people who have waited until the last minute and work out any system integration issues that pop up. We will take control of the repository at this time to minimize chances of conflicts that cause last-minute problems. If you do wait until the last moment, you are not guaranteed to get your code into ns-3.7 even if it is perfect and completely reviewed. This is a first-in first-out process (with possible priority boosts based on inputs from higher up) and will continue as long as resources allow; but don't expect any results. If you miss the start of the late merge period, or have a feature that is not design-reviewed by the start of the late merge period, well, sorry. You get to wait until the ns-3.8 open period to try again.

The end of the late merge period coincides with the beginning of the maintenance phase. No new features may be added, but the maintainers may check in fixes to bugs; and people with new features that have been accepted and previously merged may fix bugs in existing features. Please don't try to sneak in more new features or you may have your whole feature set removed at the release manager's discretion. You can ask if you want to add small, self-contained features, but there are no guarantees that we will okay them.

On January 6th, 2010, we are going to enter the code freeze phase. This indicates that we are in the final stages of the release and our primary goal is stability. During the code freeze phase, only P1 bugfixes will be allowed to be checked in. Our goal will be to reduce the number of P1 bugs to zero before the release of ns-3.7.

We will reserve the right to veto (and remove) any new feature addition if it begins to cause problems and looks like it threatens the stability of the release at any time in the release process.

Candidate Contributions for Inclusion in ns-3.7

Underwater Acoustic Network Device




MPI-based parallelization


Internet stack roadmap

NAT traversal

802.11n block ack

Waypoint mobility model

IPv6 Extension and Option Headers

ns-3.7 Features Merged


The ns-3.7 Bug List

At the completion of the ns-3.6 release, all P2 bugs will be promoted to P1 status.

Open Blockers


High Priority Non-Blockers


Craigdo 02:16, 22 October 2009 (UTC)