hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siddharth Seth <ss...@apache.org>
Subject Re: Fix versions for commits branch-0.23
Date Tue, 09 Oct 2012 18:30:23 GMT
I don't think figuring out the version of 0.23.X that a JIRA went into is
really a problem. Identifying the 2.X version that includes a specific JIRA
can be difficult though - if the JIRA is listed under the 0.23.X section
Agree with having JIRA in sync (including the 2.x version and 0.23.x
version). It'd be good to keep CHANGES.txt in sync as well since it is
maintained. (I'm not sure why we maintain both -  CHANGES.txt as well as a
fix version in JIRA).

- Sid

On Tue, Oct 9, 2012 at 9:09 AM, Robert Evans <evans@yahoo-inc.com> wrote:

> I don't see much of a reason to have the same JIRA listed under both 0.23
> and 2.0.  I can see some advantage of being able to see what went into
> 0.23.X by looking at a 2.0.X CHANGES.txt, but unless the two are released
> at exactly the same time they will be out of date with each other in the
> best cases.  I personally think the only way to truly know what is in
> 0.23.X is to look at the CHANGES.txt on 0.23.X and similarly for 2.X.
> Having JIRA be in sync is a huge help and we should definitely push for
> that.  I just don't see much value in trying very hard to have the
> CHANGES.txt stay in sync.
> --Bobby
> On 10/8/12 10:21 PM, "Siddharth Seth" <seth.siddharth@gmail.com> wrote:
> >Along with fix versions, does it make sense to add JIRAs under 0.23 as
> >well
> >as branch-2 in CHANGES.txt, if they're committed to both branches.
> >CHANGES.txt tends to get out of sync with the different release schedules
> >of the 2 branches.
> >
> >Thanks
> >- Sid
> >
> >On Sat, Sep 29, 2012 at 10:33 PM, Arun C Murthy <acm@hortonworks.com>
> >wrote:
> >
> >> Guys,
> >>
> >>  A request - can everyone please set fix-version to both 2.* and
> >>0.23.*? I
> >> found some with only 0.23.*, makes generating release-notes very hard.
> >>
> >> thanks,
> >> Arun

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