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]
