plans for next release

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

plans for next release

Tom Henderson-2
Last week at the maintainers telecon, we discussed moving back to two or
three releases per year, and possibly changing the naming scheme to be
date-based, such as ns-3.20.09 (Sept. 2020).  We also had some
discussion about feature freeze and whether and for how long to maintain
a parallel release branch with the master branch.

At the very least, I would like to propose that we plan to release again
in September, and have a soft feature freeze by early to mid-August.
There is plenty of pending code in our tracker to work through by then.

Now would be a good time to discuss again some of the broader issues
that have been raised over the past few months:

- running check-style.py on the codebase, and issues around maintaining
it going forward

- library naming scheme (issue #144)

- third-party software packaging improvements (issue #214)

- move include file location in our build directory (issue #205)

- improving how Python bindings are managed by maintainers and our CI system

Please feel free to start a thread on any of the above with proposals to
move forward.

- Tom
Reply | Threaded
Open this post in threaded view
|

Re: plans for next release

Mohit P. Tahiliani
Hi Tom,

Inline:

On Mon, Jun 29, 2020 at 8:55 PM Tom Henderson <[hidden email]> wrote:

> Last week at the maintainers telecon, we discussed moving back to two or
> three releases per year,


Yes, moving back to our previous release frequency would be nice. Two to
three releases per year would be good.

and possibly changing the naming scheme to be
> date-based, such as ns-3.20.09 (Sept. 2020).


We have been using a simple naming scheme for ns-3 since the beginning (and
it was probably the same for previous ns versions). In my opinion, changing
it to a date-based naming scheme could lead to confusion for our users
without having any additional benefits to the developers community.

While the developers in the open source community (not limited to ns-3) are
familiar with the date-based naming scheme, there are many users who do not
understand this scheme (e.g., many users don't know what 20.04 in Ubuntu
means).

I am unable to see the benefit of using ns-3.20.09, or how it would be
better/simpler than ns-3.32. The naming scheme which we are currently using
is simple to understand for our users (ns-3.32 is newer than ns-3.31).
Suppose we plan for January, May and September releases every year, but for
some reason if we're unable to make on-time releases in these months, then
the versions of ns-3 might look like ns-3.21.07 or ns-3.21.11, or it could
be any other month. Instead, it looks simple to name these releases as
ns-3.32 or ns-3.33.

So in my opinion, the current naming scheme is fine.


> We also had some
> discussion about feature freeze and whether and for how long to maintain
> a parallel release branch with the master branch.
>
> At the very least, I would like to propose that we plan to release again
> in September, and have a soft feature freeze by early to mid-August.
> There is plenty of pending code in our tracker to work through by then.
>

I agree with this timeline for the September release.

Thanks and Regards,
Mohit P. Tahiliani