Joerg Mayer wrote:
> On Tue, Mar 14, 2006 at 04:16:02PM -0600, Gerald Combs wrote:
>> The next big step in improving Ethereal's security is to branch off a
>> stable release.
>
> Not yet. We should really wait until privsep is complete, so the next
> release should really be 0.10.15.
There have been some major changes since 0.10.14 was released: dumpcap,
emem, TCP reassembly, Lua support, SSL support, Windows file dialogs,
Windows Unicode, etc. We could bump the version up to 0.11.0, but I'd
really like it to be 0.99.0.
> Sure, but that's OK ;) We spend lots of time on both, new features and
> bugfixing, and they cannot be seen differently in many cases (see the
> tcp analysis code rewrite, which eventually fixed more bugs than it
> introduced).
The TCP analysis rewrite is a rarity -- much new functionality has been
accompanied by new bugs.
> I am in favour of going to 0.99.x after we have all the features that
> are required for an eventual 1.0 release, but I'm against creating a
> branch at that time. I'd like to see an established policy of bugfixes
> only for ~ 1 month, and if nothing comes up, we could release an
> official 1.0 beta and ask everyone to do heavy testing. After 2-4 weeks
> we could then release another beta or 1.0 final. After that, we would
> start to apply the backlog of feature patches and go on as usual.
> Reason: I don't want to see development efforts split between "stable"
> and "head". It will also motivate developers to actively search and fix
> bugs.
> Whether the 1.0 branch can be maintained after head has resumed adding
> features remains to be seen - that's a manpower/motivation thing...
Would the 1-month moratorium on features apply to every release?
Also, wouldn't this result in separate branches on the developer end
anyway? If I'm working on a new feature _and_ fixing bugs, I'd most
likely have one SVN directory on my system for the new feature as well
as a "stock" directory for bug fixes, in order to avoid accidentally
checking in feature code.
