Marking affected and fixed versions in JIRA

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Marking affected and fixed versions in JIRA

Ufuk Celebi-2
Hey all,

I was wondering what the policy is for marking issues with affected and fix versions. I know that we suggested a couple of times (in different email threads) that it would be desirable in order to get an automatic changelog for releases etc.

I think the fixed versions tag is clear: you mark the version for which it was fixed.

Example: if I fix something in the current master (assuming current master has not been branched off for 0.7-incubating) and I do a back port for 0.6.1: then I mark the fix for the unreleased 0.7-incubating version and add the new release tag 0.6.2, right?

What about the affected versions tag? Just the latest unreleased version, which is affected? Or all versions, where it should be fixed (released and unreleased) as well?

– Ufuk
Reply | Threaded
Open this post in threaded view
|

Re: Marking affected and fixed versions in JIRA

Fabian Hueske
Yes, I think more discipline with JIRA issues would be definitely good and
ease the management of releases.

I'd say the affected version should be initially the version (or versions)
where the issue was identified.
We than should check which other versions are affected and add these to the
JIRA.
Only the latest minor of each major release is relevant, e.g., 0.6.1 is
sufficient for all 0.6 releases.


2014-10-08 21:50 GMT+02:00 Ufuk Celebi <[hidden email]>:

> Hey all,
>
> I was wondering what the policy is for marking issues with affected and
> fix versions. I know that we suggested a couple of times (in different
> email threads) that it would be desirable in order to get an automatic
> changelog for releases etc.
>
> I think the fixed versions tag is clear: you mark the version for which it
> was fixed.
>
> Example: if I fix something in the current master (assuming current master
> has not been branched off for 0.7-incubating) and I do a back port for
> 0.6.1: then I mark the fix for the unreleased 0.7-incubating version and
> add the new release tag 0.6.2, right?
>
> What about the affected versions tag? Just the latest unreleased version,
> which is affected? Or all versions, where it should be fixed (released and
> unreleased) as well?
>
> – Ufuk
Reply | Threaded
Open this post in threaded view
|

Re: Marking affected and fixed versions in JIRA

Robert Metzger
I would appreciate if everyone who is merging pull requests is properly
setting the "fix version" in JIRA.

So in most cases, the "fix version" is the next major release, currently
0.9.
If we're not setting this, the issue will not appear in the changelog of
the release. Also, I think that users may find JIRAs via Google, then this
information helps them to know when the feature will be available.
Also, the fancy marketing metric (XY issues resolved) is suffering ;)


By the way, does anybody know why we can not set the "fix version" for
"Closed" JIRAs (instead of "Resolved")? In the "Resolved" case, we can
still change that.


On Thu, Oct 9, 2014 at 9:46 AM, Fabian Hueske <[hidden email]> wrote:

> Yes, I think more discipline with JIRA issues would be definitely good and
> ease the management of releases.
>
> I'd say the affected version should be initially the version (or versions)
> where the issue was identified.
> We than should check which other versions are affected and add these to the
> JIRA.
> Only the latest minor of each major release is relevant, e.g., 0.6.1 is
> sufficient for all 0.6 releases.
>
>
> 2014-10-08 21:50 GMT+02:00 Ufuk Celebi <[hidden email]>:
>
> > Hey all,
> >
> > I was wondering what the policy is for marking issues with affected and
> > fix versions. I know that we suggested a couple of times (in different
> > email threads) that it would be desirable in order to get an automatic
> > changelog for releases etc.
> >
> > I think the fixed versions tag is clear: you mark the version for which
> it
> > was fixed.
> >
> > Example: if I fix something in the current master (assuming current
> master
> > has not been branched off for 0.7-incubating) and I do a back port for
> > 0.6.1: then I mark the fix for the unreleased 0.7-incubating version and
> > add the new release tag 0.6.2, right?
> >
> > What about the affected versions tag? Just the latest unreleased version,
> > which is affected? Or all versions, where it should be fixed (released
> and
> > unreleased) as well?
> >
> > – Ufuk
>
Reply | Threaded
Open this post in threaded view
|

Re: Marking affected and fixed versions in JIRA

Vasiliki Kalavri
Thanks for this Robert! I updated the gelly-related closed issues.
BTW, what's the difference between closed and resolved? Any case where we
should use one over the other?

-Vasia.

On 18 March 2015 at 10:34, Robert Metzger <[hidden email]> wrote:

> I would appreciate if everyone who is merging pull requests is properly
> setting the "fix version" in JIRA.
>
> So in most cases, the "fix version" is the next major release, currently
> 0.9.
> If we're not setting this, the issue will not appear in the changelog of
> the release. Also, I think that users may find JIRAs via Google, then this
> information helps them to know when the feature will be available.
> Also, the fancy marketing metric (XY issues resolved) is suffering ;)
>
>
> By the way, does anybody know why we can not set the "fix version" for
> "Closed" JIRAs (instead of "Resolved")? In the "Resolved" case, we can
> still change that.
>
>
> On Thu, Oct 9, 2014 at 9:46 AM, Fabian Hueske <[hidden email]> wrote:
>
> > Yes, I think more discipline with JIRA issues would be definitely good
> and
> > ease the management of releases.
> >
> > I'd say the affected version should be initially the version (or
> versions)
> > where the issue was identified.
> > We than should check which other versions are affected and add these to
> the
> > JIRA.
> > Only the latest minor of each major release is relevant, e.g., 0.6.1 is
> > sufficient for all 0.6 releases.
> >
> >
> > 2014-10-08 21:50 GMT+02:00 Ufuk Celebi <[hidden email]>:
> >
> > > Hey all,
> > >
> > > I was wondering what the policy is for marking issues with affected and
> > > fix versions. I know that we suggested a couple of times (in different
> > > email threads) that it would be desirable in order to get an automatic
> > > changelog for releases etc.
> > >
> > > I think the fixed versions tag is clear: you mark the version for which
> > it
> > > was fixed.
> > >
> > > Example: if I fix something in the current master (assuming current
> > master
> > > has not been branched off for 0.7-incubating) and I do a back port for
> > > 0.6.1: then I mark the fix for the unreleased 0.7-incubating version
> and
> > > add the new release tag 0.6.2, right?
> > >
> > > What about the affected versions tag? Just the latest unreleased
> version,
> > > which is affected? Or all versions, where it should be fixed (released
> > and
> > > unreleased) as well?
> > >
> > > – Ufuk
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Marking affected and fixed versions in JIRA

Henry Saputra
In reply to this post by Robert Metzger
+1

Will do this more diligently

On Wed, Mar 18, 2015 at 1:34 AM, Robert Metzger <[hidden email]> wrote:

> I would appreciate if everyone who is merging pull requests is properly
> setting the "fix version" in JIRA.
>
> So in most cases, the "fix version" is the next major release, currently
> 0.9.
> If we're not setting this, the issue will not appear in the changelog of
> the release. Also, I think that users may find JIRAs via Google, then this
> information helps them to know when the feature will be available.
> Also, the fancy marketing metric (XY issues resolved) is suffering ;)
>
>
> By the way, does anybody know why we can not set the "fix version" for
> "Closed" JIRAs (instead of "Resolved")? In the "Resolved" case, we can
> still change that.
>
>
> On Thu, Oct 9, 2014 at 9:46 AM, Fabian Hueske <[hidden email]> wrote:
>
>> Yes, I think more discipline with JIRA issues would be definitely good and
>> ease the management of releases.
>>
>> I'd say the affected version should be initially the version (or versions)
>> where the issue was identified.
>> We than should check which other versions are affected and add these to the
>> JIRA.
>> Only the latest minor of each major release is relevant, e.g., 0.6.1 is
>> sufficient for all 0.6 releases.
>>
>>
>> 2014-10-08 21:50 GMT+02:00 Ufuk Celebi <[hidden email]>:
>>
>> > Hey all,
>> >
>> > I was wondering what the policy is for marking issues with affected and
>> > fix versions. I know that we suggested a couple of times (in different
>> > email threads) that it would be desirable in order to get an automatic
>> > changelog for releases etc.
>> >
>> > I think the fixed versions tag is clear: you mark the version for which
>> it
>> > was fixed.
>> >
>> > Example: if I fix something in the current master (assuming current
>> master
>> > has not been branched off for 0.7-incubating) and I do a back port for
>> > 0.6.1: then I mark the fix for the unreleased 0.7-incubating version and
>> > add the new release tag 0.6.2, right?
>> >
>> > What about the affected versions tag? Just the latest unreleased version,
>> > which is affected? Or all versions, where it should be fixed (released
>> and
>> > unreleased) as well?
>> >
>> > – Ufuk
>>
Reply | Threaded
Open this post in threaded view
|

Re: Marking affected and fixed versions in JIRA

Robert Metzger
In reply to this post by Vasiliki Kalavri
@Vasia: I don't know. I use "Closed" for issues which are invalid or won't
fix.
Resolved for those that were implemented.

On Wed, Mar 18, 2015 at 2:57 PM, Vasiliki Kalavri <[hidden email]
> wrote:

> Thanks for this Robert! I updated the gelly-related closed issues.
> BTW, what's the difference between closed and resolved? Any case where we
> should use one over the other?
>
> -Vasia.
>
> On 18 March 2015 at 10:34, Robert Metzger <[hidden email]> wrote:
>
> > I would appreciate if everyone who is merging pull requests is properly
> > setting the "fix version" in JIRA.
> >
> > So in most cases, the "fix version" is the next major release, currently
> > 0.9.
> > If we're not setting this, the issue will not appear in the changelog of
> > the release. Also, I think that users may find JIRAs via Google, then
> this
> > information helps them to know when the feature will be available.
> > Also, the fancy marketing metric (XY issues resolved) is suffering ;)
> >
> >
> > By the way, does anybody know why we can not set the "fix version" for
> > "Closed" JIRAs (instead of "Resolved")? In the "Resolved" case, we can
> > still change that.
> >
> >
> > On Thu, Oct 9, 2014 at 9:46 AM, Fabian Hueske <[hidden email]>
> wrote:
> >
> > > Yes, I think more discipline with JIRA issues would be definitely good
> > and
> > > ease the management of releases.
> > >
> > > I'd say the affected version should be initially the version (or
> > versions)
> > > where the issue was identified.
> > > We than should check which other versions are affected and add these to
> > the
> > > JIRA.
> > > Only the latest minor of each major release is relevant, e.g., 0.6.1 is
> > > sufficient for all 0.6 releases.
> > >
> > >
> > > 2014-10-08 21:50 GMT+02:00 Ufuk Celebi <[hidden email]>:
> > >
> > > > Hey all,
> > > >
> > > > I was wondering what the policy is for marking issues with affected
> and
> > > > fix versions. I know that we suggested a couple of times (in
> different
> > > > email threads) that it would be desirable in order to get an
> automatic
> > > > changelog for releases etc.
> > > >
> > > > I think the fixed versions tag is clear: you mark the version for
> which
> > > it
> > > > was fixed.
> > > >
> > > > Example: if I fix something in the current master (assuming current
> > > master
> > > > has not been branched off for 0.7-incubating) and I do a back port
> for
> > > > 0.6.1: then I mark the fix for the unreleased 0.7-incubating version
> > and
> > > > add the new release tag 0.6.2, right?
> > > >
> > > > What about the affected versions tag? Just the latest unreleased
> > version,
> > > > which is affected? Or all versions, where it should be fixed
> (released
> > > and
> > > > unreleased) as well?
> > > >
> > > > – Ufuk
> > >
> >
>
mxm
Reply | Threaded
Open this post in threaded view
|

Re: Marking affected and fixed versions in JIRA

mxm
Hmm. In my eyes, "Closed" is for one-time issues that are not likely to
occur again. "Resolved" is to mark the issue as resolved with possible
issues coming up in the course of usage or testing. I would say, "Closed"
is more from an end-user perspective, whereas "Resolved" marks the
developer's result of fixing the issue.

On Fri, Mar 27, 2015 at 2:41 PM, Robert Metzger <[hidden email]> wrote:

> @Vasia: I don't know. I use "Closed" for issues which are invalid or won't
> fix.
> Resolved for those that were implemented.
>
> On Wed, Mar 18, 2015 at 2:57 PM, Vasiliki Kalavri <
> [hidden email]
> > wrote:
>
> > Thanks for this Robert! I updated the gelly-related closed issues.
> > BTW, what's the difference between closed and resolved? Any case where we
> > should use one over the other?
> >
> > -Vasia.
> >
> > On 18 March 2015 at 10:34, Robert Metzger <[hidden email]> wrote:
> >
> > > I would appreciate if everyone who is merging pull requests is properly
> > > setting the "fix version" in JIRA.
> > >
> > > So in most cases, the "fix version" is the next major release,
> currently
> > > 0.9.
> > > If we're not setting this, the issue will not appear in the changelog
> of
> > > the release. Also, I think that users may find JIRAs via Google, then
> > this
> > > information helps them to know when the feature will be available.
> > > Also, the fancy marketing metric (XY issues resolved) is suffering ;)
> > >
> > >
> > > By the way, does anybody know why we can not set the "fix version" for
> > > "Closed" JIRAs (instead of "Resolved")? In the "Resolved" case, we can
> > > still change that.
> > >
> > >
> > > On Thu, Oct 9, 2014 at 9:46 AM, Fabian Hueske <[hidden email]>
> > wrote:
> > >
> > > > Yes, I think more discipline with JIRA issues would be definitely
> good
> > > and
> > > > ease the management of releases.
> > > >
> > > > I'd say the affected version should be initially the version (or
> > > versions)
> > > > where the issue was identified.
> > > > We than should check which other versions are affected and add these
> to
> > > the
> > > > JIRA.
> > > > Only the latest minor of each major release is relevant, e.g., 0.6.1
> is
> > > > sufficient for all 0.6 releases.
> > > >
> > > >
> > > > 2014-10-08 21:50 GMT+02:00 Ufuk Celebi <[hidden email]>:
> > > >
> > > > > Hey all,
> > > > >
> > > > > I was wondering what the policy is for marking issues with affected
> > and
> > > > > fix versions. I know that we suggested a couple of times (in
> > different
> > > > > email threads) that it would be desirable in order to get an
> > automatic
> > > > > changelog for releases etc.
> > > > >
> > > > > I think the fixed versions tag is clear: you mark the version for
> > which
> > > > it
> > > > > was fixed.
> > > > >
> > > > > Example: if I fix something in the current master (assuming current
> > > > master
> > > > > has not been branched off for 0.7-incubating) and I do a back port
> > for
> > > > > 0.6.1: then I mark the fix for the unreleased 0.7-incubating
> version
> > > and
> > > > > add the new release tag 0.6.2, right?
> > > > >
> > > > > What about the affected versions tag? Just the latest unreleased
> > > version,
> > > > > which is affected? Or all versions, where it should be fixed
> > (released
> > > > and
> > > > > unreleased) as well?
> > > > >
> > > > > – Ufuk
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Marking affected and fixed versions in JIRA

Henry Saputra
+1

Developers that solve the problem by fixing the issue should change
the status to "Resolved" and the person who create the issue could
change the status to "Closed" to verify.


- Henry

On Fri, Mar 27, 2015 at 6:52 AM, Maximilian Michels <[hidden email]> wrote:

> Hmm. In my eyes, "Closed" is for one-time issues that are not likely to
> occur again. "Resolved" is to mark the issue as resolved with possible
> issues coming up in the course of usage or testing. I would say, "Closed"
> is more from an end-user perspective, whereas "Resolved" marks the
> developer's result of fixing the issue.
>
> On Fri, Mar 27, 2015 at 2:41 PM, Robert Metzger <[hidden email]> wrote:
>
>> @Vasia: I don't know. I use "Closed" for issues which are invalid or won't
>> fix.
>> Resolved for those that were implemented.
>>
>> On Wed, Mar 18, 2015 at 2:57 PM, Vasiliki Kalavri <
>> [hidden email]
>> > wrote:
>>
>> > Thanks for this Robert! I updated the gelly-related closed issues.
>> > BTW, what's the difference between closed and resolved? Any case where we
>> > should use one over the other?
>> >
>> > -Vasia.
>> >
>> > On 18 March 2015 at 10:34, Robert Metzger <[hidden email]> wrote:
>> >
>> > > I would appreciate if everyone who is merging pull requests is properly
>> > > setting the "fix version" in JIRA.
>> > >
>> > > So in most cases, the "fix version" is the next major release,
>> currently
>> > > 0.9.
>> > > If we're not setting this, the issue will not appear in the changelog
>> of
>> > > the release. Also, I think that users may find JIRAs via Google, then
>> > this
>> > > information helps them to know when the feature will be available.
>> > > Also, the fancy marketing metric (XY issues resolved) is suffering ;)
>> > >
>> > >
>> > > By the way, does anybody know why we can not set the "fix version" for
>> > > "Closed" JIRAs (instead of "Resolved")? In the "Resolved" case, we can
>> > > still change that.
>> > >
>> > >
>> > > On Thu, Oct 9, 2014 at 9:46 AM, Fabian Hueske <[hidden email]>
>> > wrote:
>> > >
>> > > > Yes, I think more discipline with JIRA issues would be definitely
>> good
>> > > and
>> > > > ease the management of releases.
>> > > >
>> > > > I'd say the affected version should be initially the version (or
>> > > versions)
>> > > > where the issue was identified.
>> > > > We than should check which other versions are affected and add these
>> to
>> > > the
>> > > > JIRA.
>> > > > Only the latest minor of each major release is relevant, e.g., 0.6.1
>> is
>> > > > sufficient for all 0.6 releases.
>> > > >
>> > > >
>> > > > 2014-10-08 21:50 GMT+02:00 Ufuk Celebi <[hidden email]>:
>> > > >
>> > > > > Hey all,
>> > > > >
>> > > > > I was wondering what the policy is for marking issues with affected
>> > and
>> > > > > fix versions. I know that we suggested a couple of times (in
>> > different
>> > > > > email threads) that it would be desirable in order to get an
>> > automatic
>> > > > > changelog for releases etc.
>> > > > >
>> > > > > I think the fixed versions tag is clear: you mark the version for
>> > which
>> > > > it
>> > > > > was fixed.
>> > > > >
>> > > > > Example: if I fix something in the current master (assuming current
>> > > > master
>> > > > > has not been branched off for 0.7-incubating) and I do a back port
>> > for
>> > > > > 0.6.1: then I mark the fix for the unreleased 0.7-incubating
>> version
>> > > and
>> > > > > add the new release tag 0.6.2, right?
>> > > > >
>> > > > > What about the affected versions tag? Just the latest unreleased
>> > > version,
>> > > > > which is affected? Or all versions, where it should be fixed
>> > (released
>> > > > and
>> > > > > unreleased) as well?
>> > > > >
>> > > > > – Ufuk
>> > > >
>> > >
>> >
>>
Reply | Threaded
Open this post in threaded view
|

Re: Marking affected and fixed versions in JIRA

Ufuk Celebi-2
On Fri, Mar 27, 2015 at 7:41 PM, Henry Saputra <[hidden email]>
wrote:

> Developers that solve the problem by fixing the issue should change
> the status to "Resolved" and the person who create the issue could
> change the status to "Closed" to verify.
>


Yes. JIRA itself says the following (there is a small text on top of the
pop up):

*Closing* an issue indicates that there is no more work to be done on it,
and that it has been verified as complete.

*Resolving* an issue indicates that the developers are satisfied the issue
is finished.

By this definition, we have a lot of resolved issues, which can actually be
closed.