: Here’s my issue with that approach. Say I commit something that would be : released with 7.0 but obviously, I also commit to master at this point. : Going with your approach here are the fix versions I’ll end up with on : the JIRA - master (8.0), 7.1, and 7.0. : : This confuses me, as anything that has a 7.0 fix version shouldn’t have : anything else from the 7x line. Also, it shouldn’t have anything from a : line greater than that i.e. master (8.0) as it is obvious to me that : there can not be any fix that makes it’s way into 7.0 but not 7.1, or : 8.0.
The problem(s) with your "obvious" assertion are: 1) just because it's "obvious" to you doesn't mean it's obvious to everyone. A user who sees that a bug is fixed in "6.6.1" has no way to be confident that the same bug is fixed in "7.0" just because the major number is greater -- because we might releast 6.6.1 after 7.0 is released. To you and I it's obvious that's a diff situation from your "8.0 vs 7.1 vs 7.0" example -- but only because we know how the branches are used and forked off of eachother. If you tell a user "any bug fiexed in 7.0.0 is by definition also fixed in 7.1.0" it is understandable for them to extrapolate that "any bug fixed in 7.0.1 is also fixed in 7.1.0" 2) It is in fact very possible for human error to result in a bug fix making it's way into 7.0.0, but not into 7.1.0 when (as they are today, post branch_7_0 creation) 2 distinct commits/merges are needed to 2 distinct branches. a philosophy of "each branch changed == a fixVersion added" helps developers sanity check their own actions vs their expectations, and gives people watching jiras enough info to sanity check a committers actions even if they don't understand the specifics of the affected code... If you commit a bug fix to your local branch_7x and branch_7_0, but something goes wrong with your push to branch_7x (perhaps a conflict because someone else has added a feature to that branch since your last merge/rebase) and you don't notice, people watching the issue who see a single commit to branch_7_0 and you setting the fixVersion=7.0 might easily assume the "bug" only affects the 7.0 release line, and doesn't exist in branch_7x due to other changes. If you explicitly set fixVersion="7.0, 7.(x|1)" but there is only 1 commit to branch_7_0 for that jira, then hopefully that raises eyebrows from other people who can ask you about it and help you catch your mistake. -Hoss http://www.lucidworks.com/
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
