[Ns-developers] ns-3.0.13 release posted

[Gustavo Carneiro]

On 03/06/2008, Tom Henderson <tomh at tomh.org> 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.


It depends on what is the definition of "unstable", and what changes between
consecutive stable releases as well.  Does it mean:

  1- Between stable releases new APIs are added, but code is strictly
backward API compatible;

  2- Between stable releases new APIs are added, others changed/removed, and
code is not backward API compatible;

In case of 2 I would suggest one year release cycle.   In case of 1 I
suggest, say, about 3 months.

In any case, I still prefer release numbers, rather than dates.  But I can
live with release dates.

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


Again, it depends on what is the definition of "unstable".   And in any case
I don't know the answer right now.  I guess it depends on time available to
the python bindings maintainer and the amount of work involved.  If there is
time, I don't see why not keeping python bindings in sync with unstable
releases as well.  But too many variables right now to decide.

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