Noone should ever forget to set the proper fix version on a jira when you resolve or close it but sometimes we forget.

Below i'm outlining how you can figure out when/where things are actually committed.

Find the matching commit

First find the commit that matches the issue. For that the simplest way is to go to the Subversion Commit tab of the issue.

This of course assumes you reference the jira in the commit message. If the jira is not referenced go hunt down the developer

and make him find it - if that is yourself, well - good hunting. svn log or http://fisheye.jboss.org might be of help to you.

Figure out what version the commit is for

When you got the commit you know the date and if it were committed in trunk or a branch.

Now if that is not enough to figure out what specific release it was in you need to start using svn log to be sure of when a commit actually happend - using the release date of JBoss Tools is not good since the release date might be a few days after the tag actually happend.

Thus svn log it is. You can use it to find when specific tags or branches happened.

To find the branch date of 3.2.x you do the following on a command line:

svn log https://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.1.x -v --stop-on-copy

This command goes back on the branch (or tag) and spits out the full log until it were created (i.e. when it were "copied")

This should give a long output which ends with something like this:

------------------------------------------------------------------------
r20399 | nickboldt | 2010-02-20 01:39:20 +0100 (Sat, 20 Feb 2010) | 1 line
Changed paths:
   D /branches/jbosstools-3.1.0.RC2
   A /branches/jbosstools-3.1.x (from /branches/jbosstools-3.1.0.RC2:20398)

rename branch from RC2 to .x
------------------------------------------------------------------------

This means that 3.1.x were done at "2010-02-20 01:39:20 +0100" and copied from the 3.1.0.RC2 branch, thus if your commit were done to this 3.1.0.RC2 branch before that date it is in 3.1.x. Of course if your commit were done in trunk you will then need to check if the RC2 branch were done before or after your trunk commit.

To know if your fix made it into a specific version (which you will need to know to set the proper fix version months after it actually happend) then you just use svn log on the specific tag. i.e. here it is for 3.2.0:

svn log https://svn.jboss.org/repos/jbosstools/tags/jbosstools-3.1.0.GA -v --stop-on-copy
------------------------------------------------------------------------
r20694 | nickboldt | 2010-03-06 00:46:43 +0100 (Sat, 06 Mar 2010) | 1 line
Changed paths:
   A /tags/jbosstools-3.1.0.GA (from /branches/jbosstools-3.1.x:20693)

tag 3.1.0.GA
------------------------------------------------------------------------

Which reveals the actual 3.1.0.GA were done on "2010-03-06 00:46:43 +0100" about 3 weeks after the branch were created.

If you don't know the exact name of the tags/branches simply browse https://svn.jboss.org/repos/jbosstools/tags or https://svn.jboss.org/repos/jbosstools/branches

What if my code does not live in JBoss Tools repo ?

This is the case for a few components such as Drools, Savara, Teiid and others. They cab do the similar tricks outlined above, but in that repo and match up what version in JBoss Tools it works with. If if in doubt on what version of Drools, Savara,etc. made it into a specific release, the simplest way is currently to ask on jbosstools-dev.

TBD: Link/page/resource where this can be found out.

Update the Jira

If an issue is already resolved or closed you need to reopen the issue, put a comment on why (i.e. "reopen to set fix version"), set the fix version and then resolve or close it (i.e. whatever it was before) and then leave additional comments for what were found. i.e. if you had to track down the specific svn commit because the jira weren't referenced then putting in a rev id or even better the fisheye link to the related commit would be good. That avoids you or others to have to do the same hunting once more.

Other resources

JBoss Tools jira changelog have trunk/branches listed + release dates (but note that is not the same day the tag where made, its TAG day + Day for QE and Release)

JBoss Developer Studio roadmap with rough maps to what JBoss Tools version it is based on

...and remember, all this could be avoided if you just always set the fix version properly when resolving/closing the issue