It's possible a release of 0.20.20X (X=5 I think) as Hadoop 1.0 is imminent.

The Hadoop 1.0 release is an acknowledgement of reality -- 0.20 branch is in production at many places.

I know we agreed to separate HBase versioning from Hadoop versioning, but if we continue to number HBase as 0.X after there is a Hadoop 1.0, there is an implicit marketing message that we feel HBase is not as ready as Hadoop.
I propose that we consider, if and when Hadoop 1.0 is released, that we release HBase 1.0 off of the 0.92 branch. A subsequent release off of trunk could be 1.1 or 2.0 at the discretion of the RM and community consensus.

Best regards,
   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)

On Wed, Nov 16, 2011 at 3:50 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
> It's possible a release of 0.20.20X (X=5 I think) as Hadoop 1.0 is imminent.
>
> The Hadoop 1.0 release is an acknowledgement of reality -- 0.20 branch is in production at many places.
>
> I know we agreed to separate HBase versioning from Hadoop versioning, but if we continue to number HBase as 0.X after there is a Hadoop 1.0, there is an implicit marketing message that we feel HBase is not as ready as Hadoop.
>
>
> I propose that we consider, if and when Hadoop 1.0 is released, that we release HBase 1.0 off of the 0.92 branch. A subsequent release off of trunk could be 1.1 or 2.0 at the discretion of the RM and community consensus.
>

Agreed.  Was thinking 0.94 could e be 1.0.0 since its getting a load
of 0.89-fb branch forward-ports.   Would have to come out right after
0.92 though.

St.Ack

I agree with Stack.
>From 0.94 to 1.0, the numbering makes sense.

Let's first get 0.92 out the door :-)

On Wed, Nov 16, 2011 at 3:52 PM, Stack <[EMAIL PROTECTED]> wrote:

> On Wed, Nov 16, 2011 at 3:50 PM, Andrew Purtell <[EMAIL PROTECTED]>
> wrote:
> > It's possible a release of 0.20.20X (X=5 I think) as Hadoop 1.0 is
> imminent.
> >
> > The Hadoop 1.0 release is an acknowledgement of reality -- 0.20 branch
> is in production at many places.
> >
> > I know we agreed to separate HBase versioning from Hadoop versioning,
> but if we continue to number HBase as 0.X after there is a Hadoop 1.0,
> there is an implicit marketing message that we feel HBase is not as ready
> as Hadoop.
> >
> >
> > I propose that we consider, if and when Hadoop 1.0 is released, that we
> release HBase 1.0 off of the 0.92 branch. A subsequent release off of trunk
> could be 1.1 or 2.0 at the discretion of the RM and community consensus.
> >
>
> Agreed.  Was thinking 0.94 could e be 1.0.0 since its getting a load
> of 0.89-fb branch forward-ports.   Would have to come out right after
> 0.92 though.
>
> St.Ack
>

I think the current state is that HBase is not as stable as Hadoop :)
Hopefully 0.92 or 0.94 will fix this - then let's talk about calling
it 1.0.

I'd also like to get our interfaces labeled for public/private before
1.0, as people expect that 1.0 software will be stricter about not
breaking things between versions, etc.

-Todd

On Wed, Nov 16, 2011 at 3:54 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> I agree with Stack.
> From 0.94 to 1.0, the numbering makes sense.
>
> Let's first get 0.92 out the door :-)
>
> On Wed, Nov 16, 2011 at 3:52 PM, Stack <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Nov 16, 2011 at 3:50 PM, Andrew Purtell <[EMAIL PROTECTED]>
>> wrote:
>> > It's possible a release of 0.20.20X (X=5 I think) as Hadoop 1.0 is
>> imminent.
>> >
>> > The Hadoop 1.0 release is an acknowledgement of reality -- 0.20 branch
>> is in production at many places.
>> >
>> > I know we agreed to separate HBase versioning from Hadoop versioning,
>> but if we continue to number HBase as 0.X after there is a Hadoop 1.0,
>> there is an implicit marketing message that we feel HBase is not as ready
>> as Hadoop.
>> >
>> >
>> > I propose that we consider, if and when Hadoop 1.0 is released, that we
>> release HBase 1.0 off of the 0.92 branch. A subsequent release off of trunk
>> could be 1.1 or 2.0 at the discretion of the RM and community consensus.
>> >
>>
>> Agreed.  Was thinking 0.94 could e be 1.0.0 since its getting a load
>> of 0.89-fb branch forward-ports.   Would have to come out right after
>> 0.92 though.
>>
>> St.Ack
>>
>

--
Todd Lipcon
Software Engineer, Cloudera

> From: Todd Lipcon <[EMAIL PROTECTED]>

> I think the current state is that HBase is not as stable as Hadoop :)
> Hopefully 0.92 or 0.94 will fix this - then let's talk about calling
> it 1.0.
Well if we are good with that characterization, then leaving HBase versioning at 0.X makes sense.

Best regards,

   - Andy

On Wed, Nov 16, 2011 at 4:01 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:
>> From: Todd Lipcon <[EMAIL PROTECTED]>
>
>> I think the current state is that HBase is not as stable as Hadoop :)
>> Hopefully 0.92 or 0.94 will fix this - then let's talk about calling
>> it 1.0.
>
>
> Well if we are good with that characterization, then leaving HBase versioning at 0.X makes sense.

I'm all for fixing the characterization, but the way to do it is to
stabilize it, not by just branding it differently.

Like Karthik said, I'm for a 1.0 but it should have a testing/burn-in
period with no major changes for a while. If major changes are needed
to fix bugs, then the base code/design isn't yet solid enough and we
aren't ready for 1.0.

-Todd
>
> Best regards,
>
>    - Andy
>
>

--
Todd Lipcon
Software Engineer, Cloudera

> From: Todd Lipcon <[EMAIL PROTECTED]>

>>  Well if we are good with that characterization, then leaving HBase
> versioning at 0.X makes sense.
>
> I'm all for fixing the characterization, but the way to do it is to
> stabilize it, not by just branding it differently.
Now hold on. That's not what I said.

What I said was having a 0.X release of HBase while there is a 1.0 release of Hadoop implies that we think HBase is **less ready** than Hadoop, as in less ready to use. There seem to be a fair number of HBase installs. I think it is ready for use. That does not mean I think always focusing on and improving stability is less important than branding.

And at some level all of this renumbering is a marketing exercise, but that's beside the point, it is coming from upstream.

   - Andy

> From: Ted Yu <[EMAIL PROTECTED]>
> Subject: Re: on HBase 1.0
> 
> I agree with Stack.
> From 0.94 to 1.0, the numbering makes sense.

You did not address the issue of having only 0.X HBase in release while a 1.0 Hadoop is in release. Do you see that as a problem?
Best regards,
   - Andy

Yes, that is a problem which should give us motivation to make 0.94 stable
in near future.

It is also natural because there're more people using/developing hadoop
compared to HBase.

On Wed, Nov 16, 2011 at 4:00 PM, Andrew Purtell <[EMAIL PROTECTED]> wrote:

> > From: Ted Yu <[EMAIL PROTECTED]>
> > Subject: Re: on HBase 1.0
> >
> > I agree with Stack.
> > From 0.94 to 1.0, the numbering makes sense.
>
> You did not address the issue of having only 0.X HBase in release while a
> 1.0 Hadoop is in release. Do you see that as a problem?
>
>
> Best regards,
>
>
>    - Andy
>
>

> From: Stack <[EMAIL PROTECTED]>

> To: [EMAIL PROTECTED]; Andrew Purtell <[EMAIL PROTECTED]>
> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Sent: Wednesday, November 16, 2011 3:52 PM
> Subject: Re: on HBase 1.0
>
> On Wed, Nov 16, 2011 at 3:50 PM, Andrew Purtell <[EMAIL PROTECTED]>
> wrote:
>>  It's possible a release of 0.20.20X (X=5 I think) as Hadoop 1.0 is
> imminent.
>>
>>  The Hadoop 1.0 release is an acknowledgement of reality -- 0.20 branch is
> in production at many places.
>>
>>  I know we agreed to separate HBase versioning from Hadoop versioning,
> but if we continue to number HBase as 0.X after there is a Hadoop 1.0, there is
> an implicit marketing message that we feel HBase is not as ready as Hadoop.
>>
>>
>>  I propose that we consider, if and when Hadoop 1.0 is released, that we
> release HBase 1.0 off of the 0.92 branch. A subsequent release off of trunk
> could be 1.1 or 2.0 at the discretion of the RM and community consensus.
>>
>
> Agreed.  Was thinking 0.94 could e be 1.0.0 since its getting a load
> of 0.89-fb branch forward-ports.   Would have to come out right after
> 0.92 though.
Releasing 0.94 as 1.0 like that, for that reason, sounds good to me, but I think that would imply 0.92 is merely a stepping stone to 1.0 aka 0.94. Perhaps that is accurate.

    - Andy

My 2 cents - whatever branch we decide to put out as 1.0, I think we
should have a stability/testing phase without adding too many features, so
that it is pretty stable to end users.
- Karthik
On 11/16/11 3:57 PM, "Andrew Purtell" <[EMAIL PROTECTED]> wrote:

>> From: Stack <[EMAIL PROTECTED]>
>
>> To: [EMAIL PROTECTED]; Andrew Purtell <[EMAIL PROTECTED]>
>> Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>> Sent: Wednesday, November 16, 2011 3:52 PM
>> Subject: Re: on HBase 1.0
>>
>> On Wed, Nov 16, 2011 at 3:50 PM, Andrew Purtell <[EMAIL PROTECTED]>
>> wrote:
>>>  It's possible a release of 0.20.20X (X=5 I think) as Hadoop 1.0 is
>> imminent.
>>>
>>>  The Hadoop 1.0 release is an acknowledgement of reality -- 0.20
>>>branch is
>> in production at many places.
>>>
>>>  I know we agreed to separate HBase versioning from Hadoop versioning,
>> but if we continue to number HBase as 0.X after there is a Hadoop 1.0,
>>there is
>> an implicit marketing message that we feel HBase is not as ready as
>>Hadoop.
>>>
>>>
>>>  I propose that we consider, if and when Hadoop 1.0 is released, that
>>>we
>> release HBase 1.0 off of the 0.92 branch. A subsequent release off of
>>trunk
>> could be 1.1 or 2.0 at the discretion of the RM and community consensus.
>>>
>>
>> Agreed.  Was thinking 0.94 could e be 1.0.0 since its getting a load
>> of 0.89-fb branch forward-ports.   Would have to come out right after
>> 0.92 though.
>
>
>Releasing 0.94 as 1.0 like that, for that reason, sounds good to me, but
>I think that would imply 0.92 is merely a stepping stone to 1.0 aka 0.94.
>Perhaps that is accurate.
>
>    - Andy
>

Personally I think before we can label it 1.0 we have to solve the RPC versioning issue,
so that clients and servers can be updated out of step.
________________________________
From: Andrew Purtell <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Sent: Wednesday, November 16, 2011 3:50 PM
Subject: on HBase 1.0

It's possible a release of 0.20.20X (X=5 I think) as Hadoop 1.0 is imminent.

The Hadoop 1.0 release is an acknowledgement of reality -- 0.20 branch is in production at many places.

I know we agreed to separate HBase versioning from Hadoop versioning, but if we continue to number HBase as 0.X after there is a Hadoop 1.0, there is an implicit marketing message that we feel HBase is not as ready as Hadoop.
I propose that we consider, if and when Hadoop 1.0 is released, that we release HBase 1.0 off of the 0.92 branch. A subsequent release off of trunk could be 1.1 or 2.0 at the discretion of the RM and community consensus.

Best regards,
   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)

On Wed, Nov 16, 2011 at 5:07 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> Personally I think before we can label it 1.0 we have to solve the RPC versioning issue,
> so that clients and servers can be updated out of step.

Lets make this a blocker for 1.0?
St.Ack

If that is realistic. (?)

Hadoop will (apparently) release without it.

----- Original Message -----
From: Stack <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
Cc: Andrew Purtell <[EMAIL PROTECTED]>; "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Sent: Wednesday, November 16, 2011 7:53 PM
Subject: Re: on HBase 1.0

On Wed, Nov 16, 2011 at 5:07 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> Personally I think before we can label it 1.0 we have to solve the RPC versioning issue,
> so that clients and servers can be updated out of step.

Lets make this a blocker for 1.0?
St.Ack

-User : this is really a core dev technical treatise :)

Some things to think about before we collaborate next Tuesday.  I think
some questions need to be really clearly understood before 1.0...

What does 1.0 mean?
- Feature complete for majority of use cases?  Ultra stable?  Something
that is long lasting?  I'm guessing all of the above, emphasis on lasting.

Are we feature complete for the 80% case?
- I know that we need & are still developing hourly snapshots.
- How confident are we about cross-DC replication? We're currently working
on master-master, which is a requirement for many of our future use cases.
- Do we have confidence about a finalized CoProcessor API?  Would it be
nice to have one rev of iteration on this once people use it en-masse?  I
know we've gone over this on the public JIRA, but it makes a big
difference once everyone feels like it's safe enough to touch.  APIs are
always tricky & iterative.
- What about HBCK -Fix?  This is a requirement for us.  Are there other
scripts that we should write to repair a broken system?  What about repair
of various ZK uses?
- When can we deprecate the old 'mapred' user API?  That's confusing.
- How do we feel about the Thrift server?  It seems like everyone has
their own customizations here.  Seems like performant & stable
multi-language support would be critical for a 1.0.

How confident are we in telling people to use HBase
- When users come to us with questions, do we normally point them to the
HBase book or some known material?
- Do we understand how to design an optimal schema?
- Do we understand options for server partitioning and hardware setup?
- What is the optimal way to create a table?
- What are recommended config settings to look at?  Why are they
recommended?
- What configs does a novice user looks at?  What configs does a power
user (not developer)?
+ I think Lars' HBase book has been a huge help here.  Aligning our 1.0
goals & recommendations with 2nd edition of his book should be critical.

In general, I think that announcing a 1.0 will mean that we will attract
more people, but also more finicky users that will be upset if they have
to look at the debug logs much & won't understand why it doesn't "just
work".  I think that's where consulting companies will come in, help, & be
happy.  I'm a little worried about the fact that there's region off-lining
issues from time-to-time, but I don't have new master experience.

In general, I wonder if it would be better to wait until 96 (1 more FF)
before announcing 1.0.  I also wonder if it would be better to stabilize
on a RC and label it 1.0 post-release when everything is smooth.  As an
example, HDFS 0.20.205 is really the best HDFS 1.0.  Then again, maybe
acting like HBase 0.94 will inevitably be 1.0 is a way to get various
groups to focus.