[Ns-developers] ns-3.0.13 release posted

[Mathieu Lacage]

On Tue, 2008-06-03 at 07:18 -0700, Tom Henderson wrote:
> 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.

I do not think gustavo suggested that we change the way we deal with our
development process. He merely suggested a different naming scheme for
our releases. 

We argued a lot about this (naming scheme) on friday locally: gcc does
the snapshot with date thing, gnome does even/odd, kde does even/odd,
proprietary crap does the snapshot with date/build number thing. Any
choice we make will be arbitrary because I don't believe that there are
real technical arguments in favor of one or the other so, why don't we
stick with what is described in the document above ? (the only reason I
am suggetsing this is that it seems more work to argue and change the
document: call me lazy if you want :)

regards,
Mathieu