Thanks for raising this thread Jan. I agree with Jan's proposal -- *it is what I already do*. And based on some responses here, what some others do as well. And as some others here have stated, I agree that we should try to only populate the fixVersion when resolving the issue (what I already do, usually. This isn't a big deal though; I review this on every issue resolution that I do.
An example where fixVersion=master that led to user confusion is here: https://issues.apache.org/jira/browse/LUCENE-6863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16806254#comment-16806254 If someone wants to know what *branches* an issue was committed to, then review the bot comments to find out. This is what I do -- I trust those comments more than I trust people to fill out JIRA metadata accurately/meaningfully :-) Mike Sokolov said: > The main use I've had for this field: as a user, I want to know whether this bug or feature has been fixed or is available in the version I am using, and if not, which version I would need to upgrade to in order to get it. For this use case I think it's important to list versions on each branch it has been ported to, up to the first major version release that included it. Naturally this use case is important but I fail to see how our proposed approach fails to address it. Maybe your point is about your intuition/assumptions on what fixVersion=7.2 (for example) *means *(to you)? Some will get that, and some won't... yet would be confused by also fixVersion=master so I suppose it's impossible to satisfy everyone's intuitions about what the semantics mean. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Sun, Jun 2, 2019 at 1:35 PM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > I put in the fix version after commit as well. > > In fact, in SOLR-11876, someone had put in a fix version involving a > backport before I committed (which I didn't notice) and I resolved it > without actually backporting. It caused a confusion, and resulted in a > backport release to go out without the fix. ☹️ > > On Sun, 2 Jun, 2019, 8:29 PM Erick Erickson, <erickerick...@gmail.com> > wrote: > >> bq. Currently we tag issues with fixVersion before commit, to indicate >> what BRANCHES we intend to commit to >> >> I don’t ;). In fact, I’d favor requiring this to be blank until a fix is >> committed. There are, as you’ve found, far too many instances where it’s >> filled in and completely inaccurate. >> >> What I prefer to put in the fixVersion is the version numbers of all the >> branches I ported the fix to. There are things we put in, say, 8x that >> never get into the next major version. How would we know which ones those >> are? >> >> Can the build tool get clever with a query about requiring the JIRA to be >> closed before using fixVersion at all? >> >> Erick >> >> > On Jun 1, 2019, at 11:58 AM, Jan Høydahl <jan....@cominvent.com> wrote: >> > >> > Currently we tag issues with fixVersion before commit, to indicate what >> BRANCHES we intend to commit to >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
