+1 This is great for development of new features in hive and making them available to useres. This also helps users who are slow to move to new version of hadoop, they can still bug fixes and features compatible with hadoop 1 in new hive 1.x releases.
It will also be easier for users to remember what hadoop version works with what version of hive. (Hive 1.x needs hadoop 1+, hive 2.x needs). On Mon, May 11, 2015 at 10:01 PM, Prasanth Jayachandran <pjayachand...@hortonworks.com> wrote: > +1 for the proposal. New branch definitely helps us moving forward quickly > with new features and deprecating the old stuffs (20S shims and mapreduce). > > Thanks > Prasanth > > > > > On Mon, May 11, 2015 at 7:20 PM -0700, "Vikram Dixit K" > <vikram.di...@gmail.com<mailto:vikram.di...@gmail.com>> wrote: > > 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
