Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # general - Naming of Hadoop releases


Copy link to this message
-
Re: Naming of Hadoop releases
Todd Lipcon 2012-03-20, 17:17
On Mon, Mar 19, 2012 at 11:02 PM, Konstantin Shvachko
<[EMAIL PROTECTED]> wrote:
> Feature freeze has been broken so many times for the .20 branch, so
> that it became a norm for the entire project rather than an exception,
> which we had in the past.

I agree we should be stricter about what feature backports we allow
into "stable" branches. Security and hflush were both necessary evils
- I'm glad now that we have them, but we should try to stay out of
these types of situations in the future where we feel compelled to
backport (or re-do in the case of hflush/sync) such large items.

>
> I don't understand this constant segregation against Hadoop .22. It is
> a perfectly usable version of Hadoop. It would be waste not to have it
> released. Very glad that universities adopted it. If somebody needs
> security there is a number of choices, Hadoop-1 being the first. But
> if you cannot afford stand-alone HBase clusters or need to combine
> general Hadoop and HBase loads there is nothing else but Hadoop 0.22
> at this point.

I don't see what HBase has to do with it. In fact HBase runs way
better on 1.x compared to 0.22. The tests don't even pass on 0.22 due
to differences in the append semantics in 0.21+ compared to 0.20.
Every production HBase deploy I know about runs on an 1.x based
distribution. You could argue this is selection bias by nature of my
employer, but the same is true based on emails to the hbase-user
lists, etc. This is orthogonal to the discussion at hand, I just
wanted to correct this lest any users get the wrong perception and
migrate their HBase clusters to a version which is rarely used and
strictly inferior for this use case.

-Todd
--
Todd Lipcon
Software Engineer, Cloudera