Bob Scheifler wrote:
Mark Brouwer wrote:
If you use it for scheduling, how do you make sure in the end that
you know what was fixed in a given release?
Through the resolution field.
OK, how do you represent something that's fixed but not yet integrated
in a release?
The way I worked when exposed to JIRA was to enter the main lines
(2.2dev) and milestones (2.2m1, 2.2m3) in JIRA as working versions and
at the end we merged them into the release version. So people could
report against non released versions and in the end we rolled it into
another version.
This can give you some problems though if you use JIRA for internal bug
reporting purposes against working versions, but there are ways to work
around it as in general you don't want to show your internal bugs in
ongoing work in release notes, etc.
> And represent something's that's fixed in one release
but still scheduled for fixing in another release?
In this case you have a problem due to having no distinction between
planned and fix version/s. There are ways to work around this for which
we must add a field and customize the workflow, but I don't know how the
various JIRA reports will act after such a change.
As this is not a change you want to do while you are on your way can you
indicate how essential you think this is. There is a possibility to just
clone issues for which a link will be created to the original and that
you can utilize to plan/report against a backport e.g.
--
Mark
