The easiest way to do that is to 'release' 2.8 on JIRA, which as part of the workflow asks what you want to do with the 2.8 items that aren't fixed. Usually we bump them all to the next version, then ask people to triage them out if they're a) assigned to them and b) not going to be worked on soon.
On 11 January 2017 at 08:52, Tim Armstrong <[email protected]> wrote: > I'll respond to the second part - I'm not sure about the first. I think we > just need to go through and move JIRAs with a target version of 2.8 to 2.9 > (or to backlog if that fits better). > > On Wed, Jan 11, 2017 at 7:16 AM, Lars Volker <[email protected]> wrote: > > > Hi all, > > > > Do we have an automated way of checking "fix version" fields for > > correctness? Out of habit I had put "Impala 2.8.0" there, until I > realized > > that the 2.8.0-rc had been cut already. I went through my changes, > manually > > checking whether the fix was included in the rc branch, and set the "fix > > version" to "impala 2.9.0" if it wasn't. Do we have tooling to validate > and > > adjust the "fix version" automatically? > > > > Similarly I noticed that some issues were created with "target version" = > > "Impala 2.8.0", but now their fixes did not make it into 2.8. Is there a > > policy what to do with those? > > > > Thanks, Lars > > > -- Henry Robinson Software Engineer Cloudera 415-994-6679
