[Ns-developers] ns-3.0.13 release posted
Tom Henderson
tomh at tomh.org
Tue Jun 3 11:03:52 PDT 2008
>-----Original Message-----
>From: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr]
>Sent: Tuesday, June 3, 2008 08:34 AM
>To: 'Tom Henderson'
>Cc: 'Gustavo Carneiro', 'ns-developers'
>Subject: Re: [Ns-developers] ns-3.0.13 release posted
>
>
>On Tue, 2008-06-03 at 07:18 -0700, Tom Henderson wrote:
>> Gustavo Carneiro wrote:
>>
>> > Regarding "Release process for unstable releases". Instead of making
>> > unstable releases ns-3-dev-yyyy-mm-dd, wouldn't it be better to use
>> > even/odd minor revisions to denote stable/unstable releases, like Linux
>> > kernel does, or GNOME?
>>
>> We could do that too; how would you envision it working for this
>> project? Longer release cycles between stable releases? It seemed a
>> bit like overkill to me but it probably depends on whether we intend to
>> make many unstable releases.
>
>I do not think gustavo suggested that we change the way we deal with our
>development process. He merely suggested a different naming scheme for
>our releases.
Yes, but I think the naming scheme should align with the development process, which is part of the issue here (whether we should make any changes to what we are now doing). Hence, my example question-- when we merge python bindings do we make a release on that feature out of ns-3-dev, or does it just get picked up in the next (stable) release?
It seems to me that if we keep to the current practice of issuing frequent, date-driven releases, and we stop maintaining the previous stable release branch once a new release is published, then it is more overhead on us and possibly more confusing to users to also maintain a similarly numbered unstable release series.
If we were to instead change to a process where stable releases were less frequent and maintained for longer and had a different notion of stability than our other releases, then I think the even/odd might be a clearer way to handle it.
- Tom
More information about the Ns-developers
mailing list