[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 11:06 +0100, Gustavo Carneiro wrote:
>
>
> >         I see this as a false choice, all or nothing.  There are
> >         degrees of making users happy or grumpy.
> >
> > I agree this "all or nothing" choice is bad.  For the record, my ideal
> > project direction would be to make major API break releases once a
> > year, and try to make minor releases with some degree of API stability
> > every couple of months in between.  So, you would make 6 releases,
> > ns-3.1, ns-3.2, ns-3.3, ..., ns-3.6.  Then you cleanup the APIs,
> > remove deprecated stuff, then make a release ns-4.1, and start another
> > cycle.
> >
> > Maintaining API stability wouldn't be bad, even for maintainers,
> > because it would be for only a year, at most.
>
> I fail to see what delaying API breakage will bring to our users.
>
> >         I am concerned about making a statement that "we'll discuss
> >         becoming API stable in a few releases" and simultaneously
> >         trying to recruit users. I'd prefer to try to sort out what
> >         are the API changes that we ought to bear some (possibly
> >         temporary) maintenance burden for, vs. changes that are safer
> >         to push onto users.
> >
> > If we don't provide API stability, what will happen is that those
> > users will end up sticking to a fixed ns version (just like most users
> > stick to one  ns-2 version).  Unfortunately, since as far as I know no
> > one is making stable ns-3 releases (e.g. ns-3.1.1), any bugs found by
> > the user will never be fixed as far as the user is concerned.
>
> 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.


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


> > In this case I can completely understand; before ns-3.1 I did not
> > really expect API stability.  But if this problem keeps repeating over
> >  and over, I'll just have to advise my colleagues to find another
> > simulation tool just so that I don't have to support them (me being
> > the only nearby "ns-3 expert").
>
> I don't think you will find other simulation tools much better with
> regard to API stability. Maybe you could point us to one of these other
> tools which uses a policy you would be comfortable with ?


Maybe NS-2... ;-)

Anyway, it would no longer be my problem, since I don't have to maintain
that code :-)

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