[Ns-developers] ns-3.0.13 release posted

[Tom Henderson]

Gustavo Carneiro wrote:
> 
> 
> On 03/06/2008, *Tom Henderson* <tomh at tomh.org <mailto: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.
> 

Sorry about that; yes, I did forget it.  I just freshened the notes.

>  
> 
>     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?

We could do that too; how would you envision it working for this 
project?  Longer release cycles between stable releases?  It seemed a 
bit like overkill to me but it probably depends on whether we intend to 
make many unstable releases.

For example, when we merge python bindings, how would you envision it 
working (for both stable and unstable inclusion)?

Tom