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?
