Ulf Lamping wrote:
>> 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.
They need to be fixed as well.
> 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 think if there's a goal in sight (e.g. "0.99.3 won't be released until
bugs 850, 855, and 858 are fixed") then there will be more of an
incentive to fix bugs.
> 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.
Sounds good. I've run into this myself in the private branches I maintain.
> 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.
Couldn't these be milestones for each 0.99 release, leading up to 1.0?
For example:
0.99.0:
Fix Coverity bugs
Fix Bugzilla "critical" and "blocker" bugs
0.99.1:
Finish capture privilege separation
TCP reassembly updates
Fix Bugzilla "critical" and "blocker" bugs
0.99.2:
Version checking.
Windows updater.
TCP reassembly updates
Fix Bugzilla "critical" and "blocker" bugs
0.99.3:
Finish TCP reassembly
Fix Bugzilla "critical" and "blocker" bugs
1.0.0:
Fix Bugzilla "critical" and "blocker" bugs
>> 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
Sounds good. Do we want to name the branches according to their target
release, e.g. "trunk-1.0" instead of "0.99"?
> 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 :-)
You probably aren't. My main focus is making our development process
more secure. If you can come up with a way to do this that's simple and
easy, I'm all ears. :)
