Well, really the "Fix for version" in JIRA isn't practically used to
state that each and every issue has been fixed for that version...
only if the issue is resolved and fix version set. The version
release muck rolls over all unresolved issues to the next version so
that folks can keep track of stuff that is still pending... its not a
commitment to fixing them in that version. But that is just how JIRA
works OOTB.
--jason
On Sep 26, 2008, at 1:55 AM, Joe Bohn wrote:
I think the problem is in setting the fix version too soon on many
of these JIRAs. For the 2.1.1 and 2.1.2 server releases I tried to
avoid setting the fix version unless it was really a target for the
release or we were ready to check-in a fix. Perhaps we can do the
same for devtools.
Joe
Ted Kirby wrote:
Yes, I think that is what I did. As part of the GEP release process,
I Administered the GERONIMODEVTOOLS JIRA project to update the
released and unreleased versions. I "managed" the 2.1.3 release, and
clicked the Release link to release it. This, I think, resulted in
all that email.
Ted
On Thu, Sep 25, 2008 at 1:48 PM, Jason Dillon
<[EMAIL PROTECTED]> wrote:
Hrm... odd, cause the default when marking a version as released
in JIRA
asks to move unresolved issues to the next version...
--jason
On Sep 26, 2008, at 12:39 AM, Donald Woods wrote:
Can we stop the blanket moving of Devtools JIRAs from one release
to the
next? We should really only move unfixed JIRAs to 2.2.0 if we have
intentions of fixing them for the 2.2.0 release. Continually
moving any
open JIRAs once GEP is released is generating way too many emails
and is not
the proper usage of the Fix Versions field in JIRA, which should
be used to
denote to the community that we're going to "try our best" to
resolve the
issue in the denoted release.....
-Donald
