[Ns-developers] Learning Bridge has been merged

[Gustavo Carneiro]

2008/7/23 Tom Henderson <tomh at tomh.org>:

> Mathieu Lacage wrote:
>
>> On Mon, 2008-07-21 at 23:05 -0700, Tom Henderson wrote:
>>
>>  Regardless of how we decide on this particular instance, we have to
>>> decide, for the long term, how we are going to maintain these base classes,
>>> and when "long term" starts if not now.
>>>
>>
>> I would like to propose starting now:
>>  - the removal of the deprecated attributes
>>  - the removal of all deprecated functions
>>  - the addition of pure keywords to all 3 methods added to NetDevice
>> and removal of SupportsPromiscuous
>>  - the documentation of each removal in RELEASE_NOTES or a more
>> appropriate file/format
>>  - the addition of a clear statement in the README and in our developer
>> documentation that we are not API stable, that our API will be changed
>> when we feel it helps clarity, coherency, etc., and that every API
>> change must be documented
>>  - schedule a discussion about API stability in 2 releases from now
>> based on the experience and data gathered during these two releases.
>>
>
> What do you think we will learn about providing API compatibility/stability
> in 2 releases from now if we punt on it now and do not try to work the issue
> in the meantime?
>
>
>> The main rationale for reverting all the efforts to provide some kind of
>> "nice" compatibility is that it seems that whatever we do is not enough
>> and will not make the "API-stable" people happy (short of really
>> freezing) and I certainly am not willing to start adding random
>> compatibility crap everywhere so, I would much rather avoid leading
>> those who want stable APIs into the false hope that we are in the
>> business of providing that.
>>
>>
> 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 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.

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

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

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