The proposal sounds good. Supporting and maintaining
hadoop-1 is hard and conflict in API changes in 2.x of hadoop keeps us
from using new and better APIs as it breaks compilation.

+1

Thanks
Vikram.

On Mon, May 11, 2015 at 7:17 PM, Sergey Shelukhin
<ser...@hortonworks.com> wrote:
> That sounds like a good idea.
> Some features could be back ported to branch-1 if viable, but at least new
> stuff would not be burdened by Hadoop 1/MR code paths.
> Probably also a good place to enable vectorization and other perf features
> by default while we make alpha releases.
>
> +1
>
> On 15/5/11, 15:38, "Alan Gates" <alanfga...@gmail.com> wrote:
>
>>There is a lot of forward-looking work going on in various branches of
>>Hive:  LLAP, the HBase metastore, and the work to drop the CLI.  It
>>would be good to have a way to release this code to users so that they
>>can experiment with it.  Releasing it will also provide feedback to
>>developers.
>>
>>At the same time there are discussions on whether to keep supporting
>>Hadoop-1.  The burden of supporting older, less used functionality such
>>as Hadoop-1 is becoming ever harder as many new features are added.
>>
>>I propose that the best way to deal with this would be to make a
>>branch-1.  We could continue to make new feature releases off of this
>>branch (1.3, 1.4, etc.).  This branch would not drop old functionality.
>>This provides stability and continuity for users and developers.
>>
>>We could then merge these new features branches (LLAP, HBase metastore,
>>CLI drop) into the trunk, as well as turn on by default newer features
>>such as the vectorization and ACID.  We could also drop older, less used
>>features such as support for Hadoop-1 and MapReduce.  It will be a while
>>before we are ready to make stable, production ready releases of this
>>code.  But we could start making alpha quality releases soon.  We would
>>call these releases 2.x, to stress the non-backward compatible changes
>>such as dropping Hadoop-1.  This will give users a chance to play with
>>the new code and developers a chance to get feedback.
>>
>>Thoughts?
>



-- 
Nothing better than when appreciated for hard work.
-Mark

Reply via email to