You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Todd Volkert <tv...@gmail.com> on 2009/08/21 16:59:06 UTC
[Discuss] JIRA "fix for version" field
Gang:
Something's been nagging at me for a little while now in JIRA; when you
select a "fix version" for a ticket, that ticket shows up as fixed in the
release notes for that version. But in the cases where the bug was
introduced *after* the previous version (just on the trunk), it never was a
bug in the previous version, so the release notes look like "hey, we fixed a
bug that never existed in a previous release!"
Concrete example: PIVOT-237 (the new SplitPane bug) is listed as "affects
1.3", "fix for 1.3". It doesn't really affect 1.3 since we'll fix it before
1.3 exists, and we don't really want it to show up in 1.3's release notes,
because as far as release notes are concerned, it's really just the
completion of PIVOT-75.
What's the best practices solution to this? I think that for such tickets,
we leave the "affects version" and "fix for version" fields blank. This
would mean that such tickets were introduced on the trunk and fixed on the
trunk before any release ever got affected. Thoughts?
-T
Re: [Discuss] JIRA "fix for version" field
Posted by Todd Volkert <tv...@gmail.com>.
Yeah, good point. Ok, I'll revert the changes I made to the 5 or so tickets
that were under this umbrella.
-T
On Sat, Aug 22, 2009 at 2:35 PM, Greg Brown <gk...@mac.com> wrote:
> It does seems a bit odd, but I'm not sure that there is a better
> alternative. Also, in those cases, wouldn't we use the "Affects version"
> field? Then, you'd see:
>
> - Add color picker (fix version: 1.3)
> - Fix color picker bug (affects version: 1.3, fix version: 1.3)
>
> which helps clarify things a bit.
>
> Or, as you said, we could manually remove those.
>
>
> On Aug 22, 2009, at 1:03 PM, Todd Volkert wrote:
>
> Ok, I'm willing to just go back to the way we were doing things with
>> respect
>> to the fix version, with one final question: am I the only one that thinks
>> it's weird to have those types of bugs show up in release notes? Imagine
>> when we add color picker, and after it's checked in, we find and fix a bug
>> in it. Then the release notes for that version will say "Add color
>> picker",
>> ....., "Fix bug in color picker".
>>
>> Alternatively, we can just hand-remove these anomalies from the
>> RELEASE-NOTES file when it comes time to release. This is probably the
>> best
>> solution.
>>
>> -T
>>
>> On Sat, Aug 22, 2009 at 7:50 AM, Greg Brown <gk...@mac.com> wrote:
>>
>> BTW, I think that if we think of "fix version" as "resolve version", it
>>> is
>>> much clearer. The current naming is unfortunate, but the field is still
>>> very
>>> useful.
>>>
>>>
>>> On Aug 22, 2009, at 7:37 AM, Greg Brown wrote:
>>>
>>> Also, I don't like the idea of using "dev" in the version name because it
>>>
>>>> will make the roadmap more confusing. I like the fact that our users can
>>>> (and do) browse the roadmap to see what is ahead.
>>>>
>>>>
>>>> On Aug 22, 2009, at 7:32 AM, Greg Brown wrote:
>>>>
>>>> I don't see any need to drop use of the "fix version" field. I agree
>>>> that
>>>>
>>>>> "affects version" is confusing, but without "fix version" we can't
>>>>> prioritize issues, and the Roadmap feature completely loses all value.
>>>>>
>>>>> On Aug 22, 2009, at 1:20 AM, Niclas Hedhman wrote:
>>>>>
>>>>> On Sat, Aug 22, 2009 at 12:23 PM, Todd Volkert<tv...@gmail.com>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> Niclas' 1.3-DEV version is the only real solution I see here, and it's
>>>>>>
>>>>>>> a
>>>>>>> solution that I've seen used before (in VMware). Then, when 1.3 is
>>>>>>> released, 1.3-DEV is removed, and all tickets marked as fix for
>>>>>>> 1.3-DEV
>>>>>>> get
>>>>>>> that field cleared.
>>>>>>>
>>>>>>>
>>>>>> Well, I was actually thinking of 1.3-DEV being the "Affects" field.
>>>>>>
>>>>>> Cheers
>>>>>> --
>>>>>> Niclas Hedhman, Software Developer
>>>>>> http://www.qi4j.org - New Energy for Java
>>>>>>
>>>>>> I live here; http://tinyurl.com/2qq9er
>>>>>> I work here; http://tinyurl.com/2ymelc
>>>>>> I relax here; http://tinyurl.com/2cgsug
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>
Re: [Discuss] JIRA "fix for version" field
Posted by Greg Brown <gk...@mac.com>.
It does seems a bit odd, but I'm not sure that there is a better
alternative. Also, in those cases, wouldn't we use the "Affects
version" field? Then, you'd see:
- Add color picker (fix version: 1.3)
- Fix color picker bug (affects version: 1.3, fix version: 1.3)
which helps clarify things a bit.
Or, as you said, we could manually remove those.
On Aug 22, 2009, at 1:03 PM, Todd Volkert wrote:
> Ok, I'm willing to just go back to the way we were doing things with
> respect
> to the fix version, with one final question: am I the only one that
> thinks
> it's weird to have those types of bugs show up in release notes?
> Imagine
> when we add color picker, and after it's checked in, we find and fix
> a bug
> in it. Then the release notes for that version will say "Add color
> picker",
> ....., "Fix bug in color picker".
>
> Alternatively, we can just hand-remove these anomalies from the
> RELEASE-NOTES file when it comes time to release. This is probably
> the best
> solution.
>
> -T
>
> On Sat, Aug 22, 2009 at 7:50 AM, Greg Brown <gk...@mac.com> wrote:
>
>> BTW, I think that if we think of "fix version" as "resolve
>> version", it is
>> much clearer. The current naming is unfortunate, but the field is
>> still very
>> useful.
>>
>>
>> On Aug 22, 2009, at 7:37 AM, Greg Brown wrote:
>>
>> Also, I don't like the idea of using "dev" in the version name
>> because it
>>> will make the roadmap more confusing. I like the fact that our
>>> users can
>>> (and do) browse the roadmap to see what is ahead.
>>>
>>>
>>> On Aug 22, 2009, at 7:32 AM, Greg Brown wrote:
>>>
>>> I don't see any need to drop use of the "fix version" field. I
>>> agree that
>>>> "affects version" is confusing, but without "fix version" we can't
>>>> prioritize issues, and the Roadmap feature completely loses all
>>>> value.
>>>>
>>>> On Aug 22, 2009, at 1:20 AM, Niclas Hedhman wrote:
>>>>
>>>> On Sat, Aug 22, 2009 at 12:23 PM, Todd Volkert<tv...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Niclas' 1.3-DEV version is the only real solution I see here,
>>>>> and it's
>>>>>> a
>>>>>> solution that I've seen used before (in VMware). Then, when
>>>>>> 1.3 is
>>>>>> released, 1.3-DEV is removed, and all tickets marked as fix for
>>>>>> 1.3-DEV
>>>>>> get
>>>>>> that field cleared.
>>>>>>
>>>>>
>>>>> Well, I was actually thinking of 1.3-DEV being the "Affects"
>>>>> field.
>>>>>
>>>>> Cheers
>>>>> --
>>>>> Niclas Hedhman, Software Developer
>>>>> http://www.qi4j.org - New Energy for Java
>>>>>
>>>>> I live here; http://tinyurl.com/2qq9er
>>>>> I work here; http://tinyurl.com/2ymelc
>>>>> I relax here; http://tinyurl.com/2cgsug
>>>>>
>>>>
>>>>
>>>
>>
Re: [Discuss] JIRA "fix for version" field
Posted by Todd Volkert <tv...@gmail.com>.
Ok, I'm willing to just go back to the way we were doing things with respect
to the fix version, with one final question: am I the only one that thinks
it's weird to have those types of bugs show up in release notes? Imagine
when we add color picker, and after it's checked in, we find and fix a bug
in it. Then the release notes for that version will say "Add color picker",
....., "Fix bug in color picker".
Alternatively, we can just hand-remove these anomalies from the
RELEASE-NOTES file when it comes time to release. This is probably the best
solution.
-T
On Sat, Aug 22, 2009 at 7:50 AM, Greg Brown <gk...@mac.com> wrote:
> BTW, I think that if we think of "fix version" as "resolve version", it is
> much clearer. The current naming is unfortunate, but the field is still very
> useful.
>
>
> On Aug 22, 2009, at 7:37 AM, Greg Brown wrote:
>
> Also, I don't like the idea of using "dev" in the version name because it
>> will make the roadmap more confusing. I like the fact that our users can
>> (and do) browse the roadmap to see what is ahead.
>>
>>
>> On Aug 22, 2009, at 7:32 AM, Greg Brown wrote:
>>
>> I don't see any need to drop use of the "fix version" field. I agree that
>>> "affects version" is confusing, but without "fix version" we can't
>>> prioritize issues, and the Roadmap feature completely loses all value.
>>>
>>> On Aug 22, 2009, at 1:20 AM, Niclas Hedhman wrote:
>>>
>>> On Sat, Aug 22, 2009 at 12:23 PM, Todd Volkert<tv...@gmail.com>
>>>> wrote:
>>>>
>>>> Niclas' 1.3-DEV version is the only real solution I see here, and it's
>>>>> a
>>>>> solution that I've seen used before (in VMware). Then, when 1.3 is
>>>>> released, 1.3-DEV is removed, and all tickets marked as fix for 1.3-DEV
>>>>> get
>>>>> that field cleared.
>>>>>
>>>>
>>>> Well, I was actually thinking of 1.3-DEV being the "Affects" field.
>>>>
>>>> Cheers
>>>> --
>>>> Niclas Hedhman, Software Developer
>>>> http://www.qi4j.org - New Energy for Java
>>>>
>>>> I live here; http://tinyurl.com/2qq9er
>>>> I work here; http://tinyurl.com/2ymelc
>>>> I relax here; http://tinyurl.com/2cgsug
>>>>
>>>
>>>
>>
>
Re: [Discuss] JIRA "fix for version" field
Posted by Greg Brown <gk...@mac.com>.
BTW, I think that if we think of "fix version" as "resolve version",
it is much clearer. The current naming is unfortunate, but the field
is still very useful.
On Aug 22, 2009, at 7:37 AM, Greg Brown wrote:
> Also, I don't like the idea of using "dev" in the version name
> because it will make the roadmap more confusing. I like the fact
> that our users can (and do) browse the roadmap to see what is ahead.
>
>
> On Aug 22, 2009, at 7:32 AM, Greg Brown wrote:
>
>> I don't see any need to drop use of the "fix version" field. I
>> agree that "affects version" is confusing, but without "fix
>> version" we can't prioritize issues, and the Roadmap feature
>> completely loses all value.
>>
>> On Aug 22, 2009, at 1:20 AM, Niclas Hedhman wrote:
>>
>>> On Sat, Aug 22, 2009 at 12:23 PM, Todd Volkert<tv...@gmail.com>
>>> wrote:
>>>
>>>> Niclas' 1.3-DEV version is the only real solution I see here, and
>>>> it's a
>>>> solution that I've seen used before (in VMware). Then, when 1.3 is
>>>> released, 1.3-DEV is removed, and all tickets marked as fix for
>>>> 1.3-DEV get
>>>> that field cleared.
>>>
>>> Well, I was actually thinking of 1.3-DEV being the "Affects" field.
>>>
>>> Cheers
>>> --
>>> Niclas Hedhman, Software Developer
>>> http://www.qi4j.org - New Energy for Java
>>>
>>> I live here; http://tinyurl.com/2qq9er
>>> I work here; http://tinyurl.com/2ymelc
>>> I relax here; http://tinyurl.com/2cgsug
>>
>
Re: [Discuss] JIRA "fix for version" field
Posted by Greg Brown <gk...@mac.com>.
Also, I don't like the idea of using "dev" in the version name because
it will make the roadmap more confusing. I like the fact that our
users can (and do) browse the roadmap to see what is ahead.
On Aug 22, 2009, at 7:32 AM, Greg Brown wrote:
> I don't see any need to drop use of the "fix version" field. I agree
> that "affects version" is confusing, but without "fix version" we
> can't prioritize issues, and the Roadmap feature completely loses
> all value.
>
> On Aug 22, 2009, at 1:20 AM, Niclas Hedhman wrote:
>
>> On Sat, Aug 22, 2009 at 12:23 PM, Todd Volkert<tv...@gmail.com>
>> wrote:
>>
>>> Niclas' 1.3-DEV version is the only real solution I see here, and
>>> it's a
>>> solution that I've seen used before (in VMware). Then, when 1.3 is
>>> released, 1.3-DEV is removed, and all tickets marked as fix for
>>> 1.3-DEV get
>>> that field cleared.
>>
>> Well, I was actually thinking of 1.3-DEV being the "Affects" field.
>>
>> Cheers
>> --
>> Niclas Hedhman, Software Developer
>> http://www.qi4j.org - New Energy for Java
>>
>> I live here; http://tinyurl.com/2qq9er
>> I work here; http://tinyurl.com/2ymelc
>> I relax here; http://tinyurl.com/2cgsug
>
Re: [Discuss] JIRA "fix for version" field
Posted by Greg Brown <gk...@mac.com>.
I don't see any need to drop use of the "fix version" field. I agree
that "affects version" is confusing, but without "fix version" we
can't prioritize issues, and the Roadmap feature completely loses all
value.
On Aug 22, 2009, at 1:20 AM, Niclas Hedhman wrote:
> On Sat, Aug 22, 2009 at 12:23 PM, Todd Volkert<tv...@gmail.com>
> wrote:
>
>> Niclas' 1.3-DEV version is the only real solution I see here, and
>> it's a
>> solution that I've seen used before (in VMware). Then, when 1.3 is
>> released, 1.3-DEV is removed, and all tickets marked as fix for 1.3-
>> DEV get
>> that field cleared.
>
> Well, I was actually thinking of 1.3-DEV being the "Affects" field.
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>
> I live here; http://tinyurl.com/2qq9er
> I work here; http://tinyurl.com/2ymelc
> I relax here; http://tinyurl.com/2cgsug
Re: [Discuss] JIRA "fix for version" field
Posted by Niclas Hedhman <ni...@hedhman.org>.
It has never occured to me...
If it is a bug, and never existed in previous versions, then I have prev
kept the Affects empty. But we could add a NONE version or have the 1.3-DEV
being present in Jira...
-- Niclas
On Aug 21, 2009 10:59 PM, "Todd Volkert" <tv...@gmail.com> wrote:
Gang:
Something's been nagging at me for a little while now in JIRA; when you
select a "fix version" for a ticket, that ticket shows up as fixed in the
release notes for that version. But in the cases where the bug was
introduced *after* the previous version (just on the trunk), it never was a
bug in the previous version, so the release notes look like "hey, we fixed a
bug that never existed in a previous release!"
Concrete example: PIVOT-237 (the new SplitPane bug) is listed as "affects
1.3", "fix for 1.3". It doesn't really affect 1.3 since we'll fix it before
1.3 exists, and we don't really want it to show up in 1.3's release notes,
because as far as release notes are concerned, it's really just the
completion of PIVOT-75.
What's the best practices solution to this? I think that for such tickets,
we leave the "affects version" and "fix for version" fields blank. This
would mean that such tickets were introduced on the trunk and fixed on the
trunk before any release ever got affected. Thoughts?
-T
Re: [Discuss] JIRA "fix for version" field
Posted by Greg Brown <gk...@mac.com>.
I've been wondering the same thing myself...
On Aug 21, 2009, at 10:59 AM, Todd Volkert wrote:
> Gang:
> Something's been nagging at me for a little while now in JIRA; when
> you
> select a "fix version" for a ticket, that ticket shows up as fixed
> in the
> release notes for that version. But in the cases where the bug was
> introduced *after* the previous version (just on the trunk), it
> never was a
> bug in the previous version, so the release notes look like "hey, we
> fixed a
> bug that never existed in a previous release!"
>
> Concrete example: PIVOT-237 (the new SplitPane bug) is listed as
> "affects
> 1.3", "fix for 1.3". It doesn't really affect 1.3 since we'll fix
> it before
> 1.3 exists, and we don't really want it to show up in 1.3's release
> notes,
> because as far as release notes are concerned, it's really just the
> completion of PIVOT-75.
>
> What's the best practices solution to this? I think that for such
> tickets,
> we leave the "affects version" and "fix for version" fields blank.
> This
> would mean that such tickets were introduced on the trunk and fixed
> on the
> trunk before any release ever got affected. Thoughts?
>
> -T