I was doing that too, but I went "to the source": https://wiki.apache.org/hadoop/HowToCommit says:
"Resolve the issue as fixed, thanking the contributor. Always set the "Fix Version" at this point, but please only set a single fix version, the earliest release in which the change will appear. Special case- when committing to a non-mainline branch (such as branch-0.22 or branch-0.23 ATM), please set fix-version to either 2.x.x or 3.x.x appropriately too." i.e., a fix that will show up in 2.6.0 should be marked as Fix Version = 2.6.0 even if that change has been committed to trunk as well. Target version doesn't appear to have any documentation around it. (I think it's confusing because branch-0.22 was *not* considered a mainline branch even though it appears to be by first glance.) That said, I just yanked all the fix versions that were both 3.0 and 2.6 and marked them as 2.6. On Sep 3, 2014, at 12:51 PM, Arpit Agarwal <aagar...@hortonworks.com> wrote: > Allen, I think the correct field you are looking for is 'Target Version'. > If a fix is committed to both branch-2 and trunk, the fix version must > include both 2.x.0 and 3.0.0. However the target version would be 2.x.0 as > that is the earliest release that includes the fix. > > > On Wed, Sep 3, 2014 at 12:45 PM, Allen Wittenauer <a...@altiscale.com> wrote: > >> >> Figured it out. Basically can only do bulk fix version edits of one >> project at a time since the versions are technically different for every >> project. >> >> i.e.,: you can edit all of YARN-xxx, but you can not do YARN-xxx and >> HDFS-xxx together. FWIW, there are 372 issues that have a fixVersion for >> 3.0.0, counting both dupe and non-dupe. The first 200: >> >> >> https://issues.apache.org/jira/sr/jira.issueviews:searchrequest-printable/temp/SearchRequest.html?jqlQuery=project+in+%28MAPREDUCE%2C+YARN%2C+HADOOP%2C+HDFS%29+AND+fixVersion+%3D+3.0.0+AND+status+%3D+resolved&tempMax=200 >> >> Clearly need to filter on 'Fixed' as well, given duplicates and won't >> fixed and invalids listed w/a fix version as well. >> >> On Sep 3, 2014, at 12:10 PM, Allen Wittenauer <a...@altiscale.com> wrote: >> >>> >>> OK, it does, but only under certain conditions. Hmm. >>> >>> On Sep 3, 2014, at 12:04 PM, Allen Wittenauer <a...@altiscale.com> wrote: >>> >>>> >>>> >>>> Looks like the web UI doesn't allow for bulk change of Fix Version. >>>> >>>> *cries* >>>> >>>> On Sep 3, 2014, at 11:56 AM, Andrew Wang <andrew.w...@cloudera.com> >> wrote: >>>> >>>>> Allen, if you're willing to do the legwork, that'd be great. I feel we >>>>> should start by getting a JIRA script checked into dev-support that >>>>> generates a changelog for a release. We could then use that to make >> sure >>>>> the various fields are set properly for previous releases, remove >>>>> CHANGES.txt once we're confident, and then use said script to generate >> the >>>>> changelog for future releases. >>>>> >>>>> >>>>> On Wed, Sep 3, 2014 at 11:47 AM, Allen Wittenauer <a...@altiscale.com> >> wrote: >>>>> >>>>>> >>>>>> On Sep 3, 2014, at 11:42 AM, Allen Wittenauer <a...@altiscale.com> >> wrote: >>>>>> >>>>>>> >>>>>>> On Sep 3, 2014, at 11:07 AM, Chris Douglas <cdoug...@apache.org> >> wrote: >>>>>>> >>>>>>>> >>>>>>>> As long as release notes and incompatible changes are recorded in >> each >>>>>>>> branch, we gain no accuracy by maintaining this manually. Commit >>>>>>>> messages that record the merge revisions instead of the change are >>>>>>>> similarly hateful. -C >>>>>>> >>>>>>> We’ll also need to get much more strict about Fix Version really only >>>>>> listing the earliest version. Many of list (next release) + (trunk), >>>>>> myself included, which after looking through some of the commit docs, >> is >>>>>> not correct. >>>>>>> >>>>>>> I’m going to make it a point to go through JIRA today and fix my >>>>>> mistakes in this regard. >>>>>> >>>>>> >>>>>> Or, if we agree, I can bulk change them for everyone too. I think >> I’ve >>>>>> got the necessary JIRA search to locate dupe fix versions. >>>> >>> >> >> > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You.
