It looks like hbase 0.20.x will be around for longer than we were planning on. Lets adapt.
We should have a 0.20.4 soon that includes hbase-2180 and, IMO, it would include a one-time breakage of the RPC interface requiring a cluster shutdown to upgrade so we can get in "HBASE-2219 stop using code mapping for method names in the RPC". We'd do this to set ourselves up for being more elastic going forward. With it in place, we can add in interface changes -- e.g. add something like the multiput, multiget, etc. -- without breaking ability to do a rolling restart as we move through 0.20.5, 0.20.6 etc. Then we should do aggressive roll out of new hbase 0.20.x versions, etc. with fixes that in particular can accomodate the evolving state of sync/flush on hadoop 0.20 branch (hdfs-200+, etc.). In hbase 0.21 we keep on with replication and master rewrite. We also take on the notion that when hbase TRUNK is baked, we'll make it run on hadoop 0.20/0.21/0.22. I'm against an hbase 1.0.0 just now. St.Ack On Wed, Feb 17, 2010 at 11:42 AM, Jean-Daniel Cryans <jdcry...@apache.org> wrote: > Hi devs, > > Yesterday Stack, Ryan, Todd (from cloudera) and me had a meeting with the FB > team about the course of action we should take with regard to Hadoop 0.21. > Since Y! doesn't seem committed to release it anytime soon (or even use it), > most users will probably stick with Hadoop 0.20. > > What it means for us is no HDFS-265 until months and this is not a situation > our users should/will tolerate. Dhruba agreed to work on HDFS-200 (and some > others) to make sure we can have an equivalent support for sync (at least > from the HBase point of view). This work is targeted at Hadoop 0.20 although > it won't probably ever be in an Apache release. > > This means that the current HBase trunk should ideally support both > 0.20+HDFS-200 and 0.21 at the same time. I opened HBASE-2233 for that. Todd > was mentioning that if HDFS-200 isn't making the rest of Hadoop unstable, > they could even package it in some sort of release of theirs and make our > users' life easier. Could be a win-win. > > Should we still name the next major HBase release as 0.21? If it becomes > common for HBase to support multiple Hadoop releases, should we still follow > their version number? Could it be time for HBase 1.0? > > Let's hear everyone's opinion. > > J-D >
