[Ns-developers] ns-3.0.13 release posted

[Gustavo Carneiro]

On 03/06/2008, Tom Henderson <tomh at tomh.org> wrote:
>
> All,
> We're beginning this month with another development release, and we plan
> to end June with our first stable ns-3 release.
>
> I've posted the development release at the below URL:
> http://www.nsnam.org/releases/ns-3.0.13.tar.bz2
>
> From the release notes:
>
> Release 3.0.13 (2008/06/02)
> ========================
> - point to point links generate ppp pcap traces
> - point to point links support asymmetrical data rates.
> - generate doxygen documentation for all attributes and trace sources
> - add ConfigStore and GtkConfigStore to contrib module
> - socket API now support tx and rx buffers: implemented for UDP and TCP
> - ARP cache now supports per-entry pending queues
> - lots of bugfixes and implementation and API cleanups


You forgot the disclaimer I asked to include regarding relative/absolute
times; please take pity on the poor souls doing simulations on top of a
unstable API :P

Here it is:


Warning: among API changes in this release, Application::Start and
Application::Stop now interprets the time argument differently.  Now the
time is assumed to be a relative to the current simulation time, in the same
way that Simulator::Schedule behaves.  Any code that calls these APIs in the
middle of the simulation will need to be adapted.  Calls done before the
start of the simulation do not need to be changed.

Although it is easily detected by a compilation error, we might as well make
the migration easier with an addition notice like:

The API of Simulator::StopAt (time) has also changed.  Now it is called
Simulator::Stop (time), and takes a relative time, instead of absolute.



Next, we plan to work on getting to our ns-3.1.0 release, scheduled for
> June 30.  I've posted some suggested revisions to our release naming and
> processes at the below wiki page:
> http://www.nsnam.org/wiki/index.php/Proposed_Release_Process


Regarding "Release process for unstable releases".  Instead of making
unstable releases ns-3-dev-yyyy-mm-dd, wouldn't it be better to use even/odd
minor revisions to denote stable/unstable releases, like Linux kernel does,
or GNOME?


Please direct any comments on the above to the list.
>
> For the first two weeks of June, we plan to work on cleanup, bug fixing,
> and preparation for a release candidate around mid-month.  If there are
> any bugs floating around that are not adequately documented in the
> tracker, please add them so that they can be triaged.
>
> - Tom
>
>


-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert