maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Rosenvold <kristian.rosenv...@gmail.com>
Subject Re: What to do with issues that are closed after release ?
Date Mon, 03 Nov 2014 16:57:30 GMT
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 <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


Mime
View raw message