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 < [email protected]> wrote: > 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] > > > > >
