hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: [REMINDER] How to set fix versions when committing
Date Tue, 30 Aug 2016 17:37:11 GMT
Hi Junping,

On Tue, Aug 30, 2016 at 4:30 AM, Junping Du <jdu@hortonworks.com> wrote:

> Hi Andrew and all,
>      Thanks for the notice on the change. I still concern this rule change
> may cause some confusion from conflicting against our previous rule - no
> need to set trunk version if it is landing on 2.x branch. As we can see,
> there are 4 cases of version setting for JIRA landing on trunk and branch-2
> now:
> 1. JIRA with fixed version set to 2.x only before 3.0.0-alpha1 cut off.
> 2. JIRA with fixed version set to 2.x only after 3.0.0-alpha1 cut off.
> 3. JIRA with fixed version set to 2.x and 3.0.0-alpha1 after 3.0.0-alpha1
> cut off.
> 4. JIRA with fixed version set to 2.x and 3.0.0-alpha2 after 3.0.0-alpha1
> cut off
>
> Case 3 and 4 can be easily distinguished, but case 1 and 2 is against our
> rule change here and hard to differentiate unless we want to mark all
> previous JIRA with fixed version for 2.x only to include
> 3.0.0-alpha1/3.0.0-alpha2. That's a tremendous effort and I doubt this
> should be our option.
>

I believe (1) was handled by the bulk fix version update I did. It added
the 3.0.0-alpha1 fix version for all JIRAs committed to trunk after the
release of 2.7.0. I filtered out branch-2 only commits based on git log.

(2) was addressed by rebranching branch-3.0.0-alpha1 after the bulk fix
version update. It should be easy to track mistakes via a JIRA query
similar to the one used to do the bulk fix version update. That code is all
posted on my github: https://github.com/umbrant/jira-update

Best,
Andrew

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message