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
