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 <[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]
