Thanks for input. I’ll start a separate email thread for discussing how we use JIRA including fixVersion :)
Jan Høydahl > 30. mai 2019 kl. 01:43 skrev Chris Hostetter <hossman_luc...@fucit.org>: > > > : I tested relasedocmaker and it digs up all the JIRA issues marked as > RESOLVED for the version and creates two files. > : CHANGELOG.md simply lists all issues under headings IMPROVEMENTS, BUG FIXES > etc > : One problem I found with how the CHANGELOG works is that it adds all issues > having the version in fixVersion, even if the feature > : was already released in an earlier version. That is because of the way we > use JIRA fixVersion, adding both e.g. "master (9.0)" and "8.2" > : at the same time, even if we know that 8.2 is the version the feature will > be released. If we stop always adding "master" to fixVersion > : but strive to keep it a list of version the feature/bugfix is FIRST > introduced, then this tool will do the correct job. > > The reason we (should always) track every fixVersion based on where things > are commited & backported is because of how important it is from the stand > point of knowing when exactly something was fixed, compared to where it > might have *needed* to be fixed. > > A bug might be found just before the 8.1.0 release that affect 7.7.0, > 8.0.0, and the current branch_8x but not master because the underlying > functionality was deprecated in 8x & removed from master -- the fix would > be committed to branch_8x and backported to branch_8_0 and branch_7_7 for > inclusion in 7.7.1 -- but maybe no one has bothered with w/an 8.0.1, and > meanwhile branch_8_1 is forked from branch_8x and already has the fix. > > if we *only* record fixVersion=7.7.1, then that can misslead people who > don't know the timing/history of the jira into thinking that if it was > fixed in 7.7.y then maybe/probably/who-knows-if it is issue in 8.x.y. > Having fixVersion=7.7.1,8.0.1,8.1.0 helps communicate several things... > > * if you are using 7.y.x lower then 7.7.1 you might be affected by this > * if you are using 8.0.y lower then 8.0.1 you might be affected by this > - since you can see in jira that 8.0.1 is unreleased: > - if/when 8.0.1 is released, it will include this fix > * if you are using 8.x.y lower then 8.1.0 then you might be affected by this > > If we *only* use fixVersion="lowest version released" it wouldn't help > people answer the question "Does this bug exist in 8.w.v if all i know is > that > the _first_ version it was fixed in was 7.x.y?" > > ...not to mention the complexity involved in _older_ bug fixe releases > happening *after* more recent feature releases with the same fix (ie: > 7.7.1 being released after 8.1.0. > > (a more rigorous use of the "affectsVersion", eg: > affectsVersion="7.7.0,7.7.1,...,7.7.0,8.0.0", can help mitigate *some* > of this confusion -- by implying that the issue does *not* affect 8.1.0 > since it isn't listed there -- but that's a lot more tedious to maintain > then just ensuring that you add a fixVersion for every place you commit) > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
