Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> [DISCUSS] More new feature backports to 0.94.


Copy link to this message
-
Re: [DISCUSS] More new feature backports to 0.94.
+1 to all of this.  Additionally, please keep in mind that when we backport
something now, we have to backport it to both 0.95 and 0.94.

- Dave
On Fri, Mar 1, 2013 at 8:31 AM, Jonathan Hsieh <[EMAIL PROTECTED]> wrote:

> I was thinking more about HBASE-7360 (backport snapshots to 0.94) and also
> saw HBASE-7965 which suggests porting some major-ish features (table locks,
> online merge) in to the apache 0.94 line.   We should chat about what we
> want to do about new features and bringing them into stable versions (0.94
> today) and in general criteria we use for future versions.
>
> This is similar to the snapshots backport discussion and earlier backport
> discussions.  Here's my understanding of  high level points we basically
> agree upon.
> * Backporting new features to the previous major version incurs more cost
> when developing new features,  pushes back efforts on making the trunk
> versions and reduces incentive to move to newer versions.
> * Backporting new features to earlier versions (0.9x.0, 0.9x.1) is
> reasonable since they are generally less stable.
> * Backporting new features to later version (0.9x.5, 0.9x.6) is less
> reasonable --  (ex: a 0.94.6, or 0.94.7 should only include robust
> features).
> * Backporting orthogonal features (snapshots) seems less risky than core
> changing features
> * An except: If multiple distributions declare intent to backport, it makes
> sense to backport a feature. (snapshots for example).
>
> Some new circumstances and discussion topics:
> * We now have a dev branch (0.95) with looser compat requirements that we
> could more readily release with dev/preview versions.  Shouldn't this
> reduce the need to backport features to the apache stable branches?  Would
> releases of these releases "replace" the 0.x.0 or 0.x.1 releases?
> * For major features in later versions we should raise the bar on the
> amount of testing probably be more explicit about what testing is done
> (unit tests not suffcient, system testing stories/resports a requirement).
>  Any other suggestions?
>
> Jon.
>
> --
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // [EMAIL PROTECTED]
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB