Gerald Combs wrote:
The next big step in improving Ethereal's security is to branch off a
stable release.
Ethereal changes quite a bit over time. The
"patch-ethereal-x-to-y.diff.bz2" files that accompany each release
typically exceed 200,000 lines. For some perspective, this is more
lines of "diff -u" than Apache has lines of code (~ 130,000).
That's really a lot, I'm surprised ...
A side effect of this high rate of change is the introduction of bugs
(some of them security-related). While a release might fix several
vulnerabilities, it will typically introduce several more.
Ack, that's the way it was in the past all the time.
Once the Coverity defect count goes to zero I plan on creating a stable
branch, which shall only receive bug fixes.
What about the bugzilla entries. I just had a look and marked all bugs
as critical which are causing a crash,
there are ten critical ones left.
However, who will actually do the bug fixing in the branches? Let's be
honest: We currently cannot (or don't want to?) keep pace with the new
bugzilla bugs rushing in. And there are not that many developers really
fixing bugs of the existing code base.
I'd like to call it "0.99"
and use it to create a "1.0" branch some time in the future, like so:
1.0---
/
0.99.0 0.99.1 0.99.x---- 1.1or2.0
/ / / /
0.10.14 0.99------------------- ?.0 ?.1 ?.x--
/ / / / /
-------------------------------------------------------> Trunk
Why creating another 1.0 branch instead of simply continuing the 0.99?
Once there's the 1.0 out there's no reason to maintain the 0.99 branch.
We can continue with 1.0.1 and so on for the stable versions.
Please don't underestimate the effort which each new branch (not
creating but maintaining it). I'm doing this all day and it can be
*very* annoying. So preventing too many branches is usually a good idea.
Why 0.99/1.0? Whether we like it or not, people have been treating
Ethereal as if it's "1.0" and have been using it in production
environments for a very long time. Calling it "alpha" or "beta" quality
with version numbers like 0.10.8 defies reality.
Ack
BUT: We shouldn't try to get a release without having release quality.
That includes IMHO at least security related things like privilege
separation and the updater function for the Win32 platform finished.
I'm not sure what to call any unstable releases that come from the trunk
_after_ the 0.99 branch, however.
Why not following the usual way "odd" for development and "even" for
releases, with a 1.2 or 2.0 for the next release and so on.
0.99.0 0.99.1 1.0.0 1.99.0 2.0.0
/ / / / /
0.10.14 0.99--------------------- 1.1.0 1.1.1 1.99--------- 2.1.0 2.1.1
/ / / / / / /
---------------------------------------------------- ... -----------------------------> Trunk
However, I'm *really* unsure if we can provide the effort of maintaining
both the developer and the release version. After a relative short time,
both versions will differ a lot, so merging changes from the release to
the devel or vice versa are practically impossible, resulting in having
to code two implementations for a bug fix (doing bug research twice,
etc.), which is obviously annoying.
Another problem is: When to release a new stable version? Doing a
release too late results in a lot of double effort and releasing it too
early results in several new fresh bugs.
Maybe I'm looking at things to complicated and this will work perfectly :-)
Regards, ULFL
