db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: What fix version to use for fixes merged to the 10.3 branch?
Date Wed, 15 Aug 2007 15:46:09 GMT
Andrew McIntyre wrote:
> On 8/14/07, Rick Hillegas <Richard.Hillegas@sun.com> 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.
>> is a moving target.
> And also can contain changes that may not be in that have
> problems, which means that would be the appropriate choice.
I think this is a rare case. However, when it occurs, the person logging 
the bug needs to tell the community the subversion timestamp of the 
snapshot which has the bug. In this rare case, we should create a new 
version id which contains the subversion timestamp, something like 
" (svn 654321)". The usage you are describing suggests to me 
that people are generating snapshots/patches outside the community, 
logging issues against those snapshots, but not giving the community 
enough information to participate in the solution.
>> 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.
The issue is not just of concern to the person fixing the bug. For the 
sake of the larger community, "head of the branch" is a moving target 
with limited value.
>> 2) The Fix Versions field? Seems like an even worse choice for that
>> field. There will never be a 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?
I'm afraid I'm lost here. It seems that this objection applies whether 
we call the "limit point" of the branch or
> 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 + 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.'
Perhaps the disconnect arises from the different patch usage patterns at 
IBM and Sun. It seems to me that IBM tends to not bump the patch id when 
generating a patch, but Sun does. Sun's usage implies that, on the eve 
of building, the head of the 10.3 branch might actually be 
tagged as

> andrew

View raw message