Cutting releases from hive

[Ashish Thusoo <at...@facebook.com>]

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

Re: Cutting releases from hive

[Dhruba Borthakur <dh...@gmail.com>]

If we are talkng about official hive releases, then I think it has to be +1
by the Hadoop PMC.

-dhruba

On Wed, Nov 26, 2008 at 4:07 PM, Joydeep Sen Sarma <js...@facebook.com>wrote:

> +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:athusoo@facebook.com]
> Sent: Wednesday, November 26, 2008 2:50 PM
> To: hive-dev@hadoop.apache.org
> 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:hammer@cloudera.com]
> Sent: Wednesday, November 26, 2008 11:51 AM
> To: hive-dev@hadoop.apache.org
> 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 <athusoo@facebook.com
> >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
>

RE: Cutting releases from hive

[Joydeep Sen Sarma <js...@facebook.com>]

+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:athusoo@facebook.com] 
Sent: Wednesday, November 26, 2008 2:50 PM
To: hive-dev@hadoop.apache.org
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:hammer@cloudera.com] 
Sent: Wednesday, November 26, 2008 11:51 AM
To: hive-dev@hadoop.apache.org
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 <at...@facebook.com>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

RE: Cutting releases from hive

[Ashish Thusoo <at...@facebook.com>]

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:hammer@cloudera.com] 
Sent: Wednesday, November 26, 2008 11:51 AM
To: hive-dev@hadoop.apache.org
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 <at...@facebook.com>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

Re: Cutting releases from hive

[Jeff Hammerbacher <ha...@cloudera.com>]

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 <at...@facebook.com>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