lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <>
Subject Re: ReleaseWizard tool
Date Thu, 30 May 2019 12:37:39 GMT
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 <>:
> : I tested relasedocmaker and it digs up all the JIRA issues marked as RESOLVED for the
version and creates two files.
> : 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message