[Ns-developers] Learning Bridge has been merged

[Gustavo Carneiro]

2008/7/23 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>:

>
> On Wed, 2008-07-23 at 16:57 +0100, Gustavo Carneiro wrote:
>
>
> >         I would be happy to see users volunteer to make "stable"
> >         releases of
> >         ns-3.1 as ns-3.1.x if they think it is a good use of their
> >         resources.
> >         i.e., if you are willing to do it, I am sure we can help you
> >         to do so.
> >
> > If this was a distributed work among all developers, maybe it'd work
> > (bug fixes are committed only into ns-3-stable, and pulled/merged
> > later into ns-3-dev).
> >
> > But a far easier approach would be to keep a single branch with at
> > least some degree of API stability.  The effort of maintaining API
> > stability is very low IMHO.  Now, you do not want to provide API
> > stability.  Fine, maybe you have better things to do.  But on top of
> > that you are stopping me from providing backward compatibility for the
> > code that I am contributing.
>
> What do you mean by "you are stopping me from providing backward
> compatibility" ? If you wish to maintain an ns-3.1.x branch, I see no
> reason why I would stop you from doing it. I would, in fact, find this
> pretty seriously cool.


Hey, don't trick me into maintaining a ns-3.1.x branch, alone! :P

I was talking about the route of _not_ branching and instead try to keep
some API stability in the single branch.  What I meant was that everything I
try to maintain API compatibility ends up hitting some maintenance rule:

  - I had initially added Node::AddPromiscProtocolHandler, you say it is too
ugly;

  - Now I make the new NetDevice methods non-virtual, you say makes the
class fragile.

So basically my hands are tied by all those rules.


>
>
> >         > Case in point.  A fellow Phd student was using ns-3.0.11 for
> >         his
> >         > research.  He wants to try TCP instead of UDP, but there
> >         were some
> >         > problems with TCP in ns-3.0.11.  He has to switch to ns-3.1,
> >         now, but
> >         > I am afraid the task is much more complex than his C++
> >         skills will
> >         > allow, and so I have the task waiting for me, to help him
> >         out.  I'll
> >         > probably spend at least a couple of days adapting to the new
> >         API.  And
> >         > it is really _tedious_ work, the suicide thought inducing
> >         kind :|
> >
> >
> >         If users used pre-3.1 releases and complain about porting to
> >         3.1, there
> >         is nothing we can do about this.
> >
> > Yes, I know.  But if this is an example of things to come, we will
> > have problems.  In my case, if API is too unstable, I will stop
> > tracking ns-3-dev after ns-3.2 (I want ns-3.2 for the python
> > bindings).  And then I would be unable to contribute any code to
> > ns-3-dev.
>
> I think that, once the python bindings in ns-3-dev build for all
> developers (it seems that there are these tricky python2.3 issues you
> tracked down with craig),


These python issues should be fixed now, as far as I could test.


> you will have two options:
>  - ask those who break the python bindings to fix them either by
> running the automatic generator or doing hand edits
>  - keep maintaining the python bindings yourself when APIs change
>
> I would be fine with either solution and I think that you should pick
> the one which works best for you. i.e., if you want us to fix the python
> bindings when we break them, I will support that strongly.


Sure, but I am concerned about C++ models, not Python.

Although, I should point out that API changes can sometimes be harder on
Python scripts than on C++ code, because there is no compile-time checking;
things just fail to run, and only if the relevant code is covered in
runtime.

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