On 8/14/07, Rick Hillegas <[EMAIL PROTECTED]> wrote: > > 1) The Affects Versions field? Seems like the wrong choice for that > field. I would expect to see a released version in that field. 10.3.1.5 > is a moving target.
And also can contain changes that may not be in 10.3.1.4 that have problems, which means that 10.3.1.5 would be the appropriate choice. > It could refer to any of a number of points in > subversion time on the 10.3 branch. That makes it inappropriate for this > field. The person reproducing the bug will want to work with a well > defined version, not a moving target. In the long view it does, in fact, refer to a very specific range of subversion changes: from the checkin where the version was bumped to the checkin where the version is bumped again (minus one rev). Since we can't put the Subversion revision where it was reproduced in this field, having the version where it was discovered is the obvious next best choice since it refers to a specific range of subversion revisions. As for the person fixing it, I would imagine that they would always be working at the head of the trunk or branch, if they're trying to fix it. > 2) The Fix Versions field? Seems like an even worse choice for that > field. There will never be a 10.3.1.5 release. If there is a new release > on the 10.3 branch, it will be called something like 10.3.2.x. Yes, but what if there is never a release on the 10.3 branch again? Then that id is the most appropriate, and that's where all of our old branches are at the moment at their head, on their last release version + 0.0.0.1. Also, I feel both the release id and current version are useful for release planning, the former says 'i'm planning on getting this done by the time the release is out' and the latter says 'i'm working on this right now.' andrew
