: 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
