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: Use of Jira "Fix In"
Date Mon, 30 Nov 2009 16:13:07 GMT
Thanks for raising this topic, Dag. I don't think we have a clear 
policy, as evidenced by the fact that we re-open some version of this 
conversation every couple months. Here's what we've got for our branches 

Branch   LastOfficialRelease   VersionOnBranch    HighestJiraVersion






trunk    n/a          

For all of the branches, we have a JIRA id for LastOfficialRelease, 
VersionOnBranch, and HighestJiraVersion. Given the community's current 
processes, I don't see a reason for JIRA to maintain both 
VersionOnBranch and HighestJiraVersion. What we do now is record the 
fact that a bug has been fixed at the head of the branch 
(VersionOnBranch). The release manager bulk-updates the fixed-in-version 
when producing a real release candidate.

I would support eliminating all of the HighestJiraVersion tags and 
merging those issues down to the corresponding VersionOnBranch.

My $0.02,

Knut Anders Hatlen wrote:
> Dag.Wanvik@Sun.COM (Dag H. Wanvik) writes:
>> Kristian Waagan <Kristian.Waagan@Sun.COM> writes:
>>> I believe we are supposed to set the fix version to the version shown
>>> by sysinfo. On the 10.5 branch it currently shows
>>> Further I thought that when / if we decide to produce a 10.5.4.X, Jira
>>> is used to bulk update all issues with fix version set to
>>> such that they will have set instead. Finally, wouldn't we
>>> remove from the list of versions in Jira, by merging it with
> I think the above is actually a single step: Merge into
> This will make all the issues marked as fixed in show
> up as fixed in, and no bulk update is needed up front.
>> This makes sense, really. But then, why have we added to JIRA
>> already? 
> To have the possibility to flag that an issue is intended to be fixed in
> the next update release. But since the current policy is to set the
> fixed-in only after the issue has actually been fixed, I don't think
> having that version tag available adds much value, and I'm +1 to
> removing it in order to keep the list of version tags shorter and less
> confusing.
>> Several of us have marked issue for fix in already; should we
>> go over those and clear that field, do you think? (as well as making
>> sure is set - and similarly for older branches..)
> It would make the bug database more consistent, so feel free... :)
>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=12314154&sorter/field=issuekey&sorter/order=DESC
> In this list, at least three issues (DERBY-4081, DERBY-4092, DERBY-4213)
> were originally marked as fixed in (this can be seen by picking
> the "All" tab). For some reason, the fix version says All of
> these issues were fixed after the release was produced and
> before it was actually released, so I'd guess something went wrong in
> the process of merging version tags into

View raw message