+1 to that. Based on all the discussions around hadoop-1700 - it seems hbase was fairly dependent on core hdfs functionality - so that may have led to the release strategy.
For the release strategy - I guess the standard route is to decide content for 0.1 (say), then cut it and then keep it open only for bug fixes. Perhaps we should take a look at the current bugs and demarcate the feature requests and then choose a subset of them that takes hive to 0.1? of the major features that keep popping up - the order-by has got to be the biggest one I imagine. If we can start by having a first release number for hive - we start targeting the bugs appropriately. Thoughts? -----Original Message----- From: Ashish Thusoo [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2008 2:50 PM To: [email protected] Subject: RE: Cutting releases from hive We did see that HBase has closely mirrored its release with hadoop, but that approach ties our releases closely with hadoop releases. An immediate fallout of that is that if today we want to create versions for 0.17, 0.18, 0.19 and trunk, we would be creating 3 more branches and many of the bug fixes that are currently happening would have to be ported to 3 more branches. That would just create a lot of development overhead. So we were thinking of following a model where the releases are indepenedent of hadoop but are certified to compile with some set of versions in hadoop. Ashish -----Original Message----- From: Jeff Hammerbacher [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 26, 2008 11:51 AM To: [email protected] Subject: Re: Cutting releases from hive Hey, Here's another thought: the HBase team initially used their own version numbers, but eventually started naming versions of HBase after Hadoop versions. It might be worth understanding why they did so, and perhaps adopting the same policy for Hive. Notably, Zookeeper and Pig do not follow this convention. Later, Jeff On Wed, Nov 26, 2008 at 10:48 AM, Ashish Thusoo <[EMAIL PROTECTED]>wrote: > Folks, > > We would want to start cutting releases for hive some time as we are > no longer tied to the hadoop releases anymore. I wanted to start some > discussion on this to determine what would be good release criteria. > Basically: > > 1. What current box we must have fixed before we cut a release 2. What > current features should go into the release > > And any other thoughts you may have... > > Ashish
