Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
MapReduce, mail # dev - Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x


Copy link to this message
-
Re: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x
Aaron T. Myers 2012-04-03, 20:58
Hi Milind,

On Tue, Apr 3, 2012 at 11:27 AM, <[EMAIL PROTECTED]> 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