On 3 November 2014 16:57, Kristian Rosenvold <[email protected]> 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 < > [email protected]>: > > 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 < > [email protected]>: > >> On 3 November 2014 16:11, Kristian Rosenvold < > [email protected]> > >> 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: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
