Thanks for the insight hoss :). I agree that I went into this with my assumptions.
> 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. The only way to confidently look at the information on the JIRA and comment on what versions have a particular feature/bug/fix is through a combination of “Affected Versions” and “fixVersions”. As David mentioned, there isn’t a single true ‘solution’ for this problem so the more information we provide the better. In what I am proposing, I am certainly resting the responsibility of providing all of that information ‘correctly’ to the users on the committer/developer. So, missing a commit, and/or fixVersion certainly does mess things up. Also, the non-linear releases that we have make it confusing for anyone who isn’t aware of the order of releases. I just wanted to highlight what I thought was missing information and I’d be happy to have an entry-per-commit as long as we think that’s the most reasonable available option. I am also not sure how adding “Affected Version” would completely help with mitigating problems like - ‘x’ was fixed in 7.2.0, 7.1.1, 7.0.2, and 6.6.3, but "affects versions” 7.1.0, 7.0.1, 6.6.2, and 6.5”. If it was a known issue in 6.4,6.3, etc. it would 1. require the developer to figure out, and provide that information, and 2. Enlist all of those versions, which might get a little too much. I don’t want to spiral this discussion and spin it off into a never ending one so whatever we all agree with, I’ll be more than happy to move ahead with it. -Anshum > On Jul 5, 2017, at 6:42 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > > : 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
