[Ns-developers] ns-3.1 roadmap
Gustavo Carneiro
gjcarneiro at gmail.com
Tue Apr 15 15:28:35 PDT 2008
On 15/04/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
> hi tom,
>
>
> On Tue, 2008-04-15 at 20:25 +0000, Tom Henderson wrote:
>
> > 3) finalize ns socket issues (existing thread)
> > - merge ns-3-simu?
>
>
> I do not plan to submit ns-3-simu for merging before our first stable
> release.
>
>
> > - other items to clean up that are not logged anywhere?
>
>
> I would like to make a pass through the XXX markers in the code and try
> to eliminate as many of them as humanly possible. I have 150 of them in
> ns-3-doc... A lot of them are missing Attribute help strings but there
> are some more or less serious code issues too.
>
>
> > - ns-3.1 or ns-3.1.0 (i.e., institute major/minor numbering, or keep
> > with ns-2 style?)
>
>
> I think that a related question is: "what type of release process do we
> want to use post 3.1 ?". The numbering scheme will most likely come
> quite naturally from that.
>
> The "classic" numbering scheme in most open source projects is not the
> ns2 way: it is a 3-number scheme: N.M.m. When N changes, it means that
> the code has changed in fundamental incompatible ways. Here, we would
> have N = 3, and, then, you get to pick M and m. Usually, when M is even,
> the version is deemed stable and, when M is odd, it is unstable. So, you
> often have two sets of releases happening at the same time: 3.M.m and
> 3.M+1.m, and, when 3.M+1.m is felt sufficiently stable, it becomes 3.M
> +2.m.
>
> To summarize, we could release 3.2.0 as our first stable release, start
> work on 3.3.1 as soon as 3.2.0 is out, and, maybe do
> strictly-compatible/bugfix releases as 3.2.1, 3.2.2, 3.2.3, etc. The
> next stable release would then be 3.4 which might introduce API changes
> compared to the 3.2 serie...
I agree, but I would also say that the interval between 3.X releases should
be at least 6 months, where 3.X may contain backward incompatible API
changes. I am _really_ tired of NS-3 incompatible API changes, and I for
one will stop contributing to NS-3 development if these API changes continue
much longer. There is a _lot_ that can be done to improve API without
making incompatible changes, so there really is little excusive for these
constant API breaks.
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
More information about the Ns-developers
mailing list