You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2014/11/03 17:11:23 UTC
What to do with issues that are closed after release ?
For some projects like assembly, there are a whole bunch of issues
that "later" will turn out to be fixed.
For instance assembly plugin had 32 fixed issues at release time, but
currently has 35 fixed issues in jira.
The problem with this is that these issues never make it into any kind
of release announcement; should I tag them as fixed in the next
release too ?
(http://jira.codehaus.org/browse/MASSEMBLY-474 is an example; fixed in
2.5 but I just recently verified the testcase)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What to do with issues that are closed after release ?
Posted by Stephen Connolly <st...@gmail.com>.
On 3 November 2014 16:57, Kristian Rosenvold <kr...@gmail.com>
wrote:
> So for something like MASSEMBLY-474 I actually committed a testcase
> for 2.5.1, which makes it a bit more logical to tag it with both 2.5
> and 2.5.1.
There were commits related to the fix in 2.5.1, thus it seems legitimate to
tag both versions for that case
> But something like MASSEMBLY-597 only requires some
> triaging on windows and should be closed without further ado if it
> turns out to be fixed; should it be tagged fixed for both 2.5 and
> 2.5.1 ?
>
if there is no commit relating to the fix in 2.5.1 but there was a commit
relating to the fix in 2.5 then I know what I would recommend
>
> K
>
>
> 2014-11-03 17:42 GMT+01:00 Kristian Rosenvold <
> kristian.rosenvold@gmail.com>:
> > The bit about the "announcement" mail is fairly obvious; that cannot
> change.
> >
> > I also think the issue should *at least* be tagged with the correct
> > version for the fix. Our jira supports multiple versions for "fixed",
> > so I could theoretically flag it as fixed for *both* 2.5 and the next
> > version, which will be 2.5.1 (or 2.6).
> >
> > So technically I "verified" the issue as fixed for 2.5.1 but it turned
> > out to also work for 2.5 (with close to 100 unfixed bugs just the
> > triaging is time consuming...)
> >
> >
> > Kristian
> >
> >
> >
> >
> > 2014-11-03 17:16 GMT+01:00 Stephen Connolly <
> stephen.alan.connolly@gmail.com>:
> >> On 3 November 2014 16:11, Kristian Rosenvold <
> kristian.rosenvold@gmail.com>
> >> wrote:
> >>
> >>> For some projects like assembly, there are a whole bunch of issues
> >>> that "later" will turn out to be fixed.
> >>>
> >>> For instance assembly plugin had 32 fixed issues at release time, but
> >>> currently has 35 fixed issues in jira.
> >>>
> >>> The problem with this is that these issues never make it into any kind
> >>> of release announcement; should I tag them as fixed in the next
> >>> release too ?
> >>>
> >>
> >> So you are suggesting adding a (to be released) version to the jira
> issue...
> >>
> >> What happens if there is a regression before you release the next
> version?
> >>
> >> I think just let JIRA reflect our best understanding of the state of
> play.
> >>
> >> Let the announcement mails reflect our best understanding of the state
> of
> >> play at that time
> >>
> >> Unless you are committing a test case towards the next version, I would
> not
> >> add it to two versions... (and we need to add it to the true fixed
> version
> >> to reflect reality)
> >>
> >>
> >>>
> >>> (http://jira.codehaus.org/browse/MASSEMBLY-474 is an example; fixed in
> >>> 2.5 but I just recently verified the testcase)
> >>>
> >>> Kristian
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: What to do with issues that are closed after release ?
Posted by Kristian Rosenvold <kr...@gmail.com>.
So for something like MASSEMBLY-474 I actually committed a testcase
for 2.5.1, which makes it a bit more logical to tag it with both 2.5
and 2.5.1. But something like MASSEMBLY-597 only requires some
triaging on windows and should be closed without further ado if it
turns out to be fixed; should it be tagged fixed for both 2.5 and
2.5.1 ?
K
2014-11-03 17:42 GMT+01:00 Kristian Rosenvold <kr...@gmail.com>:
> The bit about the "announcement" mail is fairly obvious; that cannot change.
>
> I also think the issue should *at least* be tagged with the correct
> version for the fix. Our jira supports multiple versions for "fixed",
> so I could theoretically flag it as fixed for *both* 2.5 and the next
> version, which will be 2.5.1 (or 2.6).
>
> So technically I "verified" the issue as fixed for 2.5.1 but it turned
> out to also work for 2.5 (with close to 100 unfixed bugs just the
> triaging is time consuming...)
>
>
> Kristian
>
>
>
>
> 2014-11-03 17:16 GMT+01:00 Stephen Connolly <st...@gmail.com>:
>> On 3 November 2014 16:11, Kristian Rosenvold <kr...@gmail.com>
>> wrote:
>>
>>> For some projects like assembly, there are a whole bunch of issues
>>> that "later" will turn out to be fixed.
>>>
>>> For instance assembly plugin had 32 fixed issues at release time, but
>>> currently has 35 fixed issues in jira.
>>>
>>> The problem with this is that these issues never make it into any kind
>>> of release announcement; should I tag them as fixed in the next
>>> release too ?
>>>
>>
>> So you are suggesting adding a (to be released) version to the jira issue...
>>
>> What happens if there is a regression before you release the next version?
>>
>> I think just let JIRA reflect our best understanding of the state of play.
>>
>> Let the announcement mails reflect our best understanding of the state of
>> play at that time
>>
>> Unless you are committing a test case towards the next version, I would not
>> add it to two versions... (and we need to add it to the true fixed version
>> to reflect reality)
>>
>>
>>>
>>> (http://jira.codehaus.org/browse/MASSEMBLY-474 is an example; fixed in
>>> 2.5 but I just recently verified the testcase)
>>>
>>> Kristian
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What to do with issues that are closed after release ?
Posted by Kristian Rosenvold <kr...@gmail.com>.
The bit about the "announcement" mail is fairly obvious; that cannot change.
I also think the issue should *at least* be tagged with the correct
version for the fix. Our jira supports multiple versions for "fixed",
so I could theoretically flag it as fixed for *both* 2.5 and the next
version, which will be 2.5.1 (or 2.6).
So technically I "verified" the issue as fixed for 2.5.1 but it turned
out to also work for 2.5 (with close to 100 unfixed bugs just the
triaging is time consuming...)
Kristian
2014-11-03 17:16 GMT+01:00 Stephen Connolly <st...@gmail.com>:
> On 3 November 2014 16:11, Kristian Rosenvold <kr...@gmail.com>
> wrote:
>
>> For some projects like assembly, there are a whole bunch of issues
>> that "later" will turn out to be fixed.
>>
>> For instance assembly plugin had 32 fixed issues at release time, but
>> currently has 35 fixed issues in jira.
>>
>> The problem with this is that these issues never make it into any kind
>> of release announcement; should I tag them as fixed in the next
>> release too ?
>>
>
> So you are suggesting adding a (to be released) version to the jira issue...
>
> What happens if there is a regression before you release the next version?
>
> I think just let JIRA reflect our best understanding of the state of play.
>
> Let the announcement mails reflect our best understanding of the state of
> play at that time
>
> Unless you are committing a test case towards the next version, I would not
> add it to two versions... (and we need to add it to the true fixed version
> to reflect reality)
>
>
>>
>> (http://jira.codehaus.org/browse/MASSEMBLY-474 is an example; fixed in
>> 2.5 but I just recently verified the testcase)
>>
>> Kristian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: What to do with issues that are closed after release ?
Posted by Paul Benedict <pb...@apache.org>.
I would opt to mark them Fixed in the version they were fixed. Although the
release notes emailed out are static, the JIRA release notes are dynamic. I
would look at the latter as the official list.
Cheers,
Paul
On Mon, Nov 3, 2014 at 10:16 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> On 3 November 2014 16:11, Kristian Rosenvold <kristian.rosenvold@gmail.com
> >
> wrote:
>
> > For some projects like assembly, there are a whole bunch of issues
> > that "later" will turn out to be fixed.
> >
> > For instance assembly plugin had 32 fixed issues at release time, but
> > currently has 35 fixed issues in jira.
> >
> > The problem with this is that these issues never make it into any kind
> > of release announcement; should I tag them as fixed in the next
> > release too ?
> >
>
> So you are suggesting adding a (to be released) version to the jira
> issue...
>
> What happens if there is a regression before you release the next version?
>
> I think just let JIRA reflect our best understanding of the state of play.
>
> Let the announcement mails reflect our best understanding of the state of
> play at that time
>
> Unless you are committing a test case towards the next version, I would not
> add it to two versions... (and we need to add it to the true fixed version
> to reflect reality)
>
>
> >
> > (http://jira.codehaus.org/browse/MASSEMBLY-474 is an example; fixed in
> > 2.5 but I just recently verified the testcase)
> >
> > Kristian
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: What to do with issues that are closed after release ?
Posted by Stephen Connolly <st...@gmail.com>.
On 3 November 2014 16:11, Kristian Rosenvold <kr...@gmail.com>
wrote:
> For some projects like assembly, there are a whole bunch of issues
> that "later" will turn out to be fixed.
>
> For instance assembly plugin had 32 fixed issues at release time, but
> currently has 35 fixed issues in jira.
>
> The problem with this is that these issues never make it into any kind
> of release announcement; should I tag them as fixed in the next
> release too ?
>
So you are suggesting adding a (to be released) version to the jira issue...
What happens if there is a regression before you release the next version?
I think just let JIRA reflect our best understanding of the state of play.
Let the announcement mails reflect our best understanding of the state of
play at that time
Unless you are committing a test case towards the next version, I would not
add it to two versions... (and we need to add it to the true fixed version
to reflect reality)
>
> (http://jira.codehaus.org/browse/MASSEMBLY-474 is an example; fixed in
> 2.5 but I just recently verified the testcase)
>
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>