Quoting Bryce Harrington <bryce@...260...>:
We have faced similar risk of introducing new bugs from doing quick bug fixing, yet in practice it has proven well worth the risk.
I don't know ... whatever the relative levels of risk, the risks are qualitatively different. With intensive feature work you have to be concerned with the architectural quality of the new code.
Since we don't have a developed design review process, most of the design review happens through informal mentoring by e.g. peter, JonCruz (EEEEEK), bulia and myself. I'm partly concerned that we might not be able to keep up.
All that aside, my other concern is that the odd-numbered releases are necessarily going to be buggier if we take this alternate feature/bug release approach. But I suspect that MOST users won't get the even/odd distinction and a lot will get burned. Many users don't fully grasp version numbering as it is...
What I suspect is that, like bug fixes, there are certain features that receive the bulk of the developer attention because they scratch the developer's personal itches or their own development plans, but others which haven't fit in with that process, that this approach would address more directly.
I think that's true.
Okay, what if we made it 100 points counting from now, just to try this new concept out? That'd work out to something like 10-20 features, which shouldn't be too risky but would be enough to demonstrate or falsify the idea in general.
If you think that the bug-fixing goal is important, perhaps we could follow the 100 points of rfe's with 100 points of bug fixes or something? (Or would that be too complicated?)
That might work. Ideally there would be a cooldown period between the feature and bug phases, so we would have a chance to catch and fix bugs in the newly implemented features.
-mental