On 7/15/2012 2:58 PM, Adam Wilson wrote:
The idea that bugs and new features can and should be rolled into the same release runs counter to every accepted best practice in both FOSS and Commercial wisdom. The two have VERY different velocities, bugs can be fixed in days, but new features take much longer. Consider COFF support for example, Walter has been hammering away at it for weeks now, and he isn't even 50% done, how many bugs have been fixed and confirmed resolved, in the same timespan?
Weeks is an exaggeration. And still, there have been a steady accumulation of fixes.
Also, consider that adding new features makes it significantly harder to track down regressions (is a real regression or did the new feature upset the code in an unexpected way) and the new features themselves create new bugs. If the branches are separate then it becomes trivial to determine if the new feature caused the bug, because it will show up in one and not the other. How DARE we DEMAND that our users wait 4 MONTHS for regression fixes because we are afraid of a split or a little extra work? How many users could we lose if we significantly slowed down the release cycle (and therefore the bugfix cycle) such that people are waiting many months for their fixes? The language would be perceived as dead/dying and that would be just as bad as the D1/D2 split. If you allow your past experiences to paralyze you into inaction, you will bring about the very problem you seek to avoid.
Sigh. Half say we release too often, the other half not often enough.
