You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-dev@hadoop.apache.org by Mi...@emc.com on 2012/04/03 20:27:10 UTC
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Arun,
I am even more confused now than I was before:
Here you say:
> Essentially 'trunk' is where incompatible changes *may* be committed (in
>future). We should allow for that.
On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
> We do expect 'new features' to make it to trunk before we can commit to
>either branch-1 or branch-2.
Which one is it ?
Do you expect that "new features" will always remain compatible ?
- Milind
---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by Mi...@emc.com.
Great !
Thanks @atm,
- milind
On 4/3/12 3:21 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>If that's the case then there doesn't seem to be any question here. The
>feature is in trunk, and an implementation could be done for an older
>release branch that would be compatible with that branch. Sure, the code
>to
>implement the feature is quite different between the two branches, but
>trunk will remain a superset of the functionality of the past release, so
>no issue.
>
>--
>Aaron T. Myers
>Software Engineer, Cloudera
>
>
>
>On Tue, Apr 3, 2012 at 3:14 PM, <Mi...@emc.com> wrote:
>
>> To my knowledge, shuffle is already pluggable in 0.23 onwards, as long
>>as
>> it is used only by mapreduce framework.
>>
>> That's why Avner says : "In parallel, I'll try to *learn what exists* in
>> 0.23". (Emphasize my own.)
>>
>> That's why I was wondering about the insistence of committing to trunk
>> first.
>>
>> - Milind
>>
>> ---
>> Milind Bhandarkar
>> Greenplum Labs, EMC
>> (Disclaimer: Opinions expressed in this email are those of the author,
>>and
>> do not necessarily represent the views of any organization, past or
>> present, the author might be affiliated with.)
>>
>>
>>
>> On 4/3/12 2:44 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>>
>> >On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
>> >
>> >> What would be guideline for a new feature, such as
>> >> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
>> >> compatibility for 1.x, but is not relevant to trunk, because the
>> >>codebases
>> >> have completely diverged, so cannot be committed to trunk ?
>> >>
>> >
>> >Are you sure this isn't relevant to trunk? The "target versions" field
>>of
>> >that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
>> >that JIRA, the author appears to intend to do this work for both trunk
>>and
>> >1.0:
>> >
>> >"I want to have the described plugin-ability (desired with same
>>interface)
>> >for all future versions of Hadoop (as mentioned in the Target Version/s
>> >field). <snip> On the first phase, I am focusing on the existing 1.0
>> >branch
>> >as I know it. In parallel, I'll try to learn what exists in 0.23"
>> >
>> >--
>> >Aaron T. Myers
>> >Software Engineer, Cloudera
>>
>>
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by Mi...@emc.com.
Great !
Thanks @atm,
- milind
On 4/3/12 3:21 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>If that's the case then there doesn't seem to be any question here. The
>feature is in trunk, and an implementation could be done for an older
>release branch that would be compatible with that branch. Sure, the code
>to
>implement the feature is quite different between the two branches, but
>trunk will remain a superset of the functionality of the past release, so
>no issue.
>
>--
>Aaron T. Myers
>Software Engineer, Cloudera
>
>
>
>On Tue, Apr 3, 2012 at 3:14 PM, <Mi...@emc.com> wrote:
>
>> To my knowledge, shuffle is already pluggable in 0.23 onwards, as long
>>as
>> it is used only by mapreduce framework.
>>
>> That's why Avner says : "In parallel, I'll try to *learn what exists* in
>> 0.23". (Emphasize my own.)
>>
>> That's why I was wondering about the insistence of committing to trunk
>> first.
>>
>> - Milind
>>
>> ---
>> Milind Bhandarkar
>> Greenplum Labs, EMC
>> (Disclaimer: Opinions expressed in this email are those of the author,
>>and
>> do not necessarily represent the views of any organization, past or
>> present, the author might be affiliated with.)
>>
>>
>>
>> On 4/3/12 2:44 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>>
>> >On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
>> >
>> >> What would be guideline for a new feature, such as
>> >> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
>> >> compatibility for 1.x, but is not relevant to trunk, because the
>> >>codebases
>> >> have completely diverged, so cannot be committed to trunk ?
>> >>
>> >
>> >Are you sure this isn't relevant to trunk? The "target versions" field
>>of
>> >that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
>> >that JIRA, the author appears to intend to do this work for both trunk
>>and
>> >1.0:
>> >
>> >"I want to have the described plugin-ability (desired with same
>>interface)
>> >for all future versions of Hadoop (as mentioned in the Target Version/s
>> >field). <snip> On the first phase, I am focusing on the existing 1.0
>> >branch
>> >as I know it. In parallel, I'll try to learn what exists in 0.23"
>> >
>> >--
>> >Aaron T. Myers
>> >Software Engineer, Cloudera
>>
>>
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by Mi...@emc.com.
Great !
Thanks @atm,
- milind
On 4/3/12 3:21 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>If that's the case then there doesn't seem to be any question here. The
>feature is in trunk, and an implementation could be done for an older
>release branch that would be compatible with that branch. Sure, the code
>to
>implement the feature is quite different between the two branches, but
>trunk will remain a superset of the functionality of the past release, so
>no issue.
>
>--
>Aaron T. Myers
>Software Engineer, Cloudera
>
>
>
>On Tue, Apr 3, 2012 at 3:14 PM, <Mi...@emc.com> wrote:
>
>> To my knowledge, shuffle is already pluggable in 0.23 onwards, as long
>>as
>> it is used only by mapreduce framework.
>>
>> That's why Avner says : "In parallel, I'll try to *learn what exists* in
>> 0.23". (Emphasize my own.)
>>
>> That's why I was wondering about the insistence of committing to trunk
>> first.
>>
>> - Milind
>>
>> ---
>> Milind Bhandarkar
>> Greenplum Labs, EMC
>> (Disclaimer: Opinions expressed in this email are those of the author,
>>and
>> do not necessarily represent the views of any organization, past or
>> present, the author might be affiliated with.)
>>
>>
>>
>> On 4/3/12 2:44 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>>
>> >On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
>> >
>> >> What would be guideline for a new feature, such as
>> >> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
>> >> compatibility for 1.x, but is not relevant to trunk, because the
>> >>codebases
>> >> have completely diverged, so cannot be committed to trunk ?
>> >>
>> >
>> >Are you sure this isn't relevant to trunk? The "target versions" field
>>of
>> >that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
>> >that JIRA, the author appears to intend to do this work for both trunk
>>and
>> >1.0:
>> >
>> >"I want to have the described plugin-ability (desired with same
>>interface)
>> >for all future versions of Hadoop (as mentioned in the Target Version/s
>> >field). <snip> On the first phase, I am focusing on the existing 1.0
>> >branch
>> >as I know it. In parallel, I'll try to learn what exists in 0.23"
>> >
>> >--
>> >Aaron T. Myers
>> >Software Engineer, Cloudera
>>
>>
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by "Aaron T. Myers" <at...@cloudera.com>.
If that's the case then there doesn't seem to be any question here. The
feature is in trunk, and an implementation could be done for an older
release branch that would be compatible with that branch. Sure, the code to
implement the feature is quite different between the two branches, but
trunk will remain a superset of the functionality of the past release, so
no issue.
--
Aaron T. Myers
Software Engineer, Cloudera
On Tue, Apr 3, 2012 at 3:14 PM, <Mi...@emc.com> wrote:
> To my knowledge, shuffle is already pluggable in 0.23 onwards, as long as
> it is used only by mapreduce framework.
>
> That's why Avner says : "In parallel, I'll try to *learn what exists* in
> 0.23". (Emphasize my own.)
>
> That's why I was wondering about the insistence of committing to trunk
> first.
>
> - Milind
>
> ---
> Milind Bhandarkar
> Greenplum Labs, EMC
> (Disclaimer: Opinions expressed in this email are those of the author, and
> do not necessarily represent the views of any organization, past or
> present, the author might be affiliated with.)
>
>
>
> On 4/3/12 2:44 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>
> >On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
> >
> >> What would be guideline for a new feature, such as
> >> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
> >> compatibility for 1.x, but is not relevant to trunk, because the
> >>codebases
> >> have completely diverged, so cannot be committed to trunk ?
> >>
> >
> >Are you sure this isn't relevant to trunk? The "target versions" field of
> >that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
> >that JIRA, the author appears to intend to do this work for both trunk and
> >1.0:
> >
> >"I want to have the described plugin-ability (desired with same interface)
> >for all future versions of Hadoop (as mentioned in the Target Version/s
> >field). <snip> On the first phase, I am focusing on the existing 1.0
> >branch
> >as I know it. In parallel, I'll try to learn what exists in 0.23"
> >
> >--
> >Aaron T. Myers
> >Software Engineer, Cloudera
>
>
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by "Aaron T. Myers" <at...@cloudera.com>.
If that's the case then there doesn't seem to be any question here. The
feature is in trunk, and an implementation could be done for an older
release branch that would be compatible with that branch. Sure, the code to
implement the feature is quite different between the two branches, but
trunk will remain a superset of the functionality of the past release, so
no issue.
--
Aaron T. Myers
Software Engineer, Cloudera
On Tue, Apr 3, 2012 at 3:14 PM, <Mi...@emc.com> wrote:
> To my knowledge, shuffle is already pluggable in 0.23 onwards, as long as
> it is used only by mapreduce framework.
>
> That's why Avner says : "In parallel, I'll try to *learn what exists* in
> 0.23". (Emphasize my own.)
>
> That's why I was wondering about the insistence of committing to trunk
> first.
>
> - Milind
>
> ---
> Milind Bhandarkar
> Greenplum Labs, EMC
> (Disclaimer: Opinions expressed in this email are those of the author, and
> do not necessarily represent the views of any organization, past or
> present, the author might be affiliated with.)
>
>
>
> On 4/3/12 2:44 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>
> >On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
> >
> >> What would be guideline for a new feature, such as
> >> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
> >> compatibility for 1.x, but is not relevant to trunk, because the
> >>codebases
> >> have completely diverged, so cannot be committed to trunk ?
> >>
> >
> >Are you sure this isn't relevant to trunk? The "target versions" field of
> >that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
> >that JIRA, the author appears to intend to do this work for both trunk and
> >1.0:
> >
> >"I want to have the described plugin-ability (desired with same interface)
> >for all future versions of Hadoop (as mentioned in the Target Version/s
> >field). <snip> On the first phase, I am focusing on the existing 1.0
> >branch
> >as I know it. In parallel, I'll try to learn what exists in 0.23"
> >
> >--
> >Aaron T. Myers
> >Software Engineer, Cloudera
>
>
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by "Aaron T. Myers" <at...@cloudera.com>.
If that's the case then there doesn't seem to be any question here. The
feature is in trunk, and an implementation could be done for an older
release branch that would be compatible with that branch. Sure, the code to
implement the feature is quite different between the two branches, but
trunk will remain a superset of the functionality of the past release, so
no issue.
--
Aaron T. Myers
Software Engineer, Cloudera
On Tue, Apr 3, 2012 at 3:14 PM, <Mi...@emc.com> wrote:
> To my knowledge, shuffle is already pluggable in 0.23 onwards, as long as
> it is used only by mapreduce framework.
>
> That's why Avner says : "In parallel, I'll try to *learn what exists* in
> 0.23". (Emphasize my own.)
>
> That's why I was wondering about the insistence of committing to trunk
> first.
>
> - Milind
>
> ---
> Milind Bhandarkar
> Greenplum Labs, EMC
> (Disclaimer: Opinions expressed in this email are those of the author, and
> do not necessarily represent the views of any organization, past or
> present, the author might be affiliated with.)
>
>
>
> On 4/3/12 2:44 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>
> >On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
> >
> >> What would be guideline for a new feature, such as
> >> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
> >> compatibility for 1.x, but is not relevant to trunk, because the
> >>codebases
> >> have completely diverged, so cannot be committed to trunk ?
> >>
> >
> >Are you sure this isn't relevant to trunk? The "target versions" field of
> >that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
> >that JIRA, the author appears to intend to do this work for both trunk and
> >1.0:
> >
> >"I want to have the described plugin-ability (desired with same interface)
> >for all future versions of Hadoop (as mentioned in the Target Version/s
> >field). <snip> On the first phase, I am focusing on the existing 1.0
> >branch
> >as I know it. In parallel, I'll try to learn what exists in 0.23"
> >
> >--
> >Aaron T. Myers
> >Software Engineer, Cloudera
>
>
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by Mi...@emc.com.
To my knowledge, shuffle is already pluggable in 0.23 onwards, as long as
it is used only by mapreduce framework.
That's why Avner says : "In parallel, I'll try to *learn what exists* in
0.23". (Emphasize my own.)
That's why I was wondering about the insistence of committing to trunk
first.
- Milind
---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)
On 4/3/12 2:44 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
>
>> What would be guideline for a new feature, such as
>> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
>> compatibility for 1.x, but is not relevant to trunk, because the
>>codebases
>> have completely diverged, so cannot be committed to trunk ?
>>
>
>Are you sure this isn't relevant to trunk? The "target versions" field of
>that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
>that JIRA, the author appears to intend to do this work for both trunk and
>1.0:
>
>"I want to have the described plugin-ability (desired with same interface)
>for all future versions of Hadoop (as mentioned in the Target Version/s
>field). <snip> On the first phase, I am focusing on the existing 1.0
>branch
>as I know it. In parallel, I'll try to learn what exists in 0.23"
>
>--
>Aaron T. Myers
>Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by Mi...@emc.com.
To my knowledge, shuffle is already pluggable in 0.23 onwards, as long as
it is used only by mapreduce framework.
That's why Avner says : "In parallel, I'll try to *learn what exists* in
0.23". (Emphasize my own.)
That's why I was wondering about the insistence of committing to trunk
first.
- Milind
---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)
On 4/3/12 2:44 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
>
>> What would be guideline for a new feature, such as
>> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
>> compatibility for 1.x, but is not relevant to trunk, because the
>>codebases
>> have completely diverged, so cannot be committed to trunk ?
>>
>
>Are you sure this isn't relevant to trunk? The "target versions" field of
>that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
>that JIRA, the author appears to intend to do this work for both trunk and
>1.0:
>
>"I want to have the described plugin-ability (desired with same interface)
>for all future versions of Hadoop (as mentioned in the Target Version/s
>field). <snip> On the first phase, I am focusing on the existing 1.0
>branch
>as I know it. In parallel, I'll try to learn what exists in 0.23"
>
>--
>Aaron T. Myers
>Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by Mi...@emc.com.
To my knowledge, shuffle is already pluggable in 0.23 onwards, as long as
it is used only by mapreduce framework.
That's why Avner says : "In parallel, I'll try to *learn what exists* in
0.23". (Emphasize my own.)
That's why I was wondering about the insistence of committing to trunk
first.
- Milind
---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)
On 4/3/12 2:44 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
>
>> What would be guideline for a new feature, such as
>> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
>> compatibility for 1.x, but is not relevant to trunk, because the
>>codebases
>> have completely diverged, so cannot be committed to trunk ?
>>
>
>Are you sure this isn't relevant to trunk? The "target versions" field of
>that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
>that JIRA, the author appears to intend to do this work for both trunk and
>1.0:
>
>"I want to have the described plugin-ability (desired with same interface)
>for all future versions of Hadoop (as mentioned in the Target Version/s
>field). <snip> On the first phase, I am focusing on the existing 1.0
>branch
>as I know it. In parallel, I'll try to learn what exists in 0.23"
>
>--
>Aaron T. Myers
>Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by "Aaron T. Myers" <at...@cloudera.com>.
On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
> What would be guideline for a new feature, such as
> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
> compatibility for 1.x, but is not relevant to trunk, because the codebases
> have completely diverged, so cannot be committed to trunk ?
>
Are you sure this isn't relevant to trunk? The "target versions" field of
that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
that JIRA, the author appears to intend to do this work for both trunk and
1.0:
"I want to have the described plugin-ability (desired with same interface)
for all future versions of Hadoop (as mentioned in the Target Version/s
field). <snip> On the first phase, I am focusing on the existing 1.0 branch
as I know it. In parallel, I'll try to learn what exists in 0.23"
--
Aaron T. Myers
Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by "Aaron T. Myers" <at...@cloudera.com>.
On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
> What would be guideline for a new feature, such as
> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
> compatibility for 1.x, but is not relevant to trunk, because the codebases
> have completely diverged, so cannot be committed to trunk ?
>
Are you sure this isn't relevant to trunk? The "target versions" field of
that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
that JIRA, the author appears to intend to do this work for both trunk and
1.0:
"I want to have the described plugin-ability (desired with same interface)
for all future versions of Hadoop (as mentioned in the Target Version/s
field). <snip> On the first phase, I am focusing on the existing 1.0 branch
as I know it. In parallel, I'll try to learn what exists in 0.23"
--
Aaron T. Myers
Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by "Aaron T. Myers" <at...@cloudera.com>.
On Tue, Apr 3, 2012 at 2:37 PM, <Mi...@emc.com> wrote:
> What would be guideline for a new feature, such as
> https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
> compatibility for 1.x, but is not relevant to trunk, because the codebases
> have completely diverged, so cannot be committed to trunk ?
>
Are you sure this isn't relevant to trunk? The "target versions" field of
that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
that JIRA, the author appears to intend to do this work for both trunk and
1.0:
"I want to have the described plugin-ability (desired with same interface)
for all future versions of Hadoop (as mentioned in the Target Version/s
field). <snip> On the first phase, I am focusing on the existing 1.0 branch
as I know it. In parallel, I'll try to learn what exists in 0.23"
--
Aaron T. Myers
Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by Mi...@emc.com.
Thanks ATM.
I guess the "*may*" emphasis confused me.
Just to get some more clarity:
What would be guideline for a new feature, such as
https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
compatibility for 1.x, but is not relevant to trunk, because the codebases
have completely diverged, so cannot be committed to trunk ?
- Milind
---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)
On 4/3/12 1:58 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>Hi Milind,
>
>On Tue, Apr 3, 2012 at 11:27 AM, <Mi...@emc.com> wrote:
>
>> Here you say:
>>
>>
>> > Essentially 'trunk' is where incompatible changes *may* be committed
>>(in
>> >future). We should allow for that.
>>
>
>What I believe Arun is alluding to here is that we expect for
>compatibility
>to be maintained for the lifetime of a major release branch.
>
>
>>
>> On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
>>
>> > We do expect 'new features' to make it to trunk before we can commit
>>to
>> >either branch-1 or branch-2.
>>
>>
>> Which one is it ?
>>
>
>These two statements aren't mutually exclusive. We require that all new
>features go to trunk first so as to ensure that future releases are
>supersets of the functionality of previous releases, except in the case of
>explicit deprecation. Only once it's committed to trunk may it be
>back-ported to an earlier branch.
>
>
>>
>> Do you expect that "new features" will always remain compatible ?
>>
>
>Not necessarily, but only if a feature is compatible may it be back-ported
>to major release branches.
>
>--
>Aaron T. Myers
>Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by Mi...@emc.com.
Thanks ATM.
I guess the "*may*" emphasis confused me.
Just to get some more clarity:
What would be guideline for a new feature, such as
https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
compatibility for 1.x, but is not relevant to trunk, because the codebases
have completely diverged, so cannot be committed to trunk ?
- Milind
---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)
On 4/3/12 1:58 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>Hi Milind,
>
>On Tue, Apr 3, 2012 at 11:27 AM, <Mi...@emc.com> wrote:
>
>> Here you say:
>>
>>
>> > Essentially 'trunk' is where incompatible changes *may* be committed
>>(in
>> >future). We should allow for that.
>>
>
>What I believe Arun is alluding to here is that we expect for
>compatibility
>to be maintained for the lifetime of a major release branch.
>
>
>>
>> On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
>>
>> > We do expect 'new features' to make it to trunk before we can commit
>>to
>> >either branch-1 or branch-2.
>>
>>
>> Which one is it ?
>>
>
>These two statements aren't mutually exclusive. We require that all new
>features go to trunk first so as to ensure that future releases are
>supersets of the functionality of previous releases, except in the case of
>explicit deprecation. Only once it's committed to trunk may it be
>back-ported to an earlier branch.
>
>
>>
>> Do you expect that "new features" will always remain compatible ?
>>
>
>Not necessarily, but only if a feature is compatible may it be back-ported
>to major release branches.
>
>--
>Aaron T. Myers
>Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by Mi...@emc.com.
Thanks ATM.
I guess the "*may*" emphasis confused me.
Just to get some more clarity:
What would be guideline for a new feature, such as
https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
compatibility for 1.x, but is not relevant to trunk, because the codebases
have completely diverged, so cannot be committed to trunk ?
- Milind
---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)
On 4/3/12 1:58 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:
>Hi Milind,
>
>On Tue, Apr 3, 2012 at 11:27 AM, <Mi...@emc.com> wrote:
>
>> Here you say:
>>
>>
>> > Essentially 'trunk' is where incompatible changes *may* be committed
>>(in
>> >future). We should allow for that.
>>
>
>What I believe Arun is alluding to here is that we expect for
>compatibility
>to be maintained for the lifetime of a major release branch.
>
>
>>
>> On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
>>
>> > We do expect 'new features' to make it to trunk before we can commit
>>to
>> >either branch-1 or branch-2.
>>
>>
>> Which one is it ?
>>
>
>These two statements aren't mutually exclusive. We require that all new
>features go to trunk first so as to ensure that future releases are
>supersets of the functionality of previous releases, except in the case of
>explicit deprecation. Only once it's committed to trunk may it be
>back-ported to an earlier branch.
>
>
>>
>> Do you expect that "new features" will always remain compatible ?
>>
>
>Not necessarily, but only if a feature is compatible may it be back-ported
>to major release branches.
>
>--
>Aaron T. Myers
>Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by "Aaron T. Myers" <at...@cloudera.com>.
Hi Milind,
On Tue, Apr 3, 2012 at 11:27 AM, <Mi...@emc.com> wrote:
> Here you say:
>
>
> > Essentially 'trunk' is where incompatible changes *may* be committed (in
> >future). We should allow for that.
>
What I believe Arun is alluding to here is that we expect for compatibility
to be maintained for the lifetime of a major release branch.
>
> On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
>
> > We do expect 'new features' to make it to trunk before we can commit to
> >either branch-1 or branch-2.
>
>
> Which one is it ?
>
These two statements aren't mutually exclusive. We require that all new
features go to trunk first so as to ensure that future releases are
supersets of the functionality of previous releases, except in the case of
explicit deprecation. Only once it's committed to trunk may it be
back-ported to an earlier branch.
>
> Do you expect that "new features" will always remain compatible ?
>
Not necessarily, but only if a feature is compatible may it be back-ported
to major release branches.
--
Aaron T. Myers
Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by "Aaron T. Myers" <at...@cloudera.com>.
Hi Milind,
On Tue, Apr 3, 2012 at 11:27 AM, <Mi...@emc.com> wrote:
> Here you say:
>
>
> > Essentially 'trunk' is where incompatible changes *may* be committed (in
> >future). We should allow for that.
>
What I believe Arun is alluding to here is that we expect for compatibility
to be maintained for the lifetime of a major release branch.
>
> On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
>
> > We do expect 'new features' to make it to trunk before we can commit to
> >either branch-1 or branch-2.
>
>
> Which one is it ?
>
These two statements aren't mutually exclusive. We require that all new
features go to trunk first so as to ensure that future releases are
supersets of the functionality of previous releases, except in the case of
explicit deprecation. Only once it's committed to trunk may it be
back-ported to an earlier branch.
>
> Do you expect that "new features" will always remain compatible ?
>
Not necessarily, but only if a feature is compatible may it be back-ported
to major release branches.
--
Aaron T. Myers
Software Engineer, Cloudera
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Posted by "Aaron T. Myers" <at...@cloudera.com>.
Hi Milind,
On Tue, Apr 3, 2012 at 11:27 AM, <Mi...@emc.com> wrote:
> Here you say:
>
>
> > Essentially 'trunk' is where incompatible changes *may* be committed (in
> >future). We should allow for that.
>
What I believe Arun is alluding to here is that we expect for compatibility
to be maintained for the lifetime of a major release branch.
>
> On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
>
> > We do expect 'new features' to make it to trunk before we can commit to
> >either branch-1 or branch-2.
>
>
> Which one is it ?
>
These two statements aren't mutually exclusive. We require that all new
features go to trunk first so as to ensure that future releases are
supersets of the functionality of previous releases, except in the case of
explicit deprecation. Only once it's committed to trunk may it be
back-ported to an earlier branch.
>
> Do you expect that "new features" will always remain compatible ?
>
Not necessarily, but only if a feature is compatible may it be back-ported
to major release branches.
--
Aaron T. Myers
Software Engineer, Cloudera