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" <a...@cloudera.com> wrote: >Hi Milind, > >On Tue, Apr 3, 2012 at 11:27 AM, <milind.bhandar...@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
