>
> I admit the concept of affects/fix for was unclear to me at the
> beginning when I was starting with Jira (we have our own install in
> Carrot2). What I explained is what we've come to agree on and is based
> on trial-and-error really. It just worked best for us. Having "affects
> version" set to a non-released artefact name is not really informative
> and only pollutes the set of suggestions with names that are not
> really pointing to anything.
>
The way it works in practice is that we set both "affects version" and "fix
version" mostly for bugs found in the already released software, while for
new features and refactorings, we set only the "fix version". In both
cases, the "fix version" denotes the version in which we'd like to ship the
bug fix or new feature. With this schema, a simple search of issues with a
specific "fix version" shows how much progress we made towards the release.
One thing to watch for is issues without "fix version", which can easily
get forgotten/lost.
At one organization I worked for (size of software and team comparable to
Lucene/Solr), we used the above system with all alpha and RC releases
defined in JIRA. New alpha/RC were added to JIRA at the point of releasing
the current alpha/RC. This system was indispensable for devs and QA to
track which bugs and features they should expect to see fixed in the
specific release. At some point, if no issues were to be fixed in some RC,
the RC would become the official stable release. JIRA lets you merge
several versions (alpha/RCs) into one, and this would usually be done after
the official release to get rid of the intermediate internal milestones.
>From what I see, Lucene/Solr has a very similar process, so defining one or
more 4.0 alpha / beta releases in JIRA and then scheduling bugs and
features for it ("fix version") should work :-)
Staszek
