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
