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 >> Porting policy from 0.96+ to 0.94


Copy link to this message
-
Re: Porting policy from 0.96+ to 0.94
If we do branch 0.96 from 0.94, then release current trunk as 0.98, it
might be confusing, no? Maybe a 0.95, if we wanna go that path?

Andrew and Lars's comments seem reasonable to me.

Enis

On Mon, Aug 20, 2012 at 4:18 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> Hmm... Reading the other responses... It seems there're more different
> opinions here.
> Thanks for bringing this up Enis.
>
> I can see a 0.96 branched from 0.94 without PB and some of the other 0.96
> "singularity" features. (Although then the question arises: How would that
> be different from the 0.94.x?)
>
>
> -- Lars
>
>
>
> ________________________________
>  From: lars hofhansl <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; "
> [EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Sent: Monday, August 20, 2012 1:56 PM
> Subject: Re: Porting policy from 0.96+ to 0.94
>
> Since 0.94 will probably be a long lived version with many releases
> (thinking about 0.94.2 already),we should back port all changes that:
> 1. Do not break client/server compatibility (in both directions)
>
> 2. Do not break server/server compatibility
> 3. Do not rely on extensive refactoring that happened only in trunk
> 4. Are not just cosmetic
> 5. Do not just represent refactoring without any features added or bugs
> fixed
>
>
> It includes bug fixes, performance improvements, even new features, etc.
> But nothing that represents risk without an appropriate benefit.
>
>
> #1 and #2 are hard rules, the rest is obviously subject to interpretation.
>
> In terms of UI changes. We probably want to keep mere face lifts out, but
> include changes that provide extra information (new metrics, etc).
> We definitely want any integrations tests back ported, unless the
> supporting changes to non-test code are extensive.
>
>
> TL;DR: Back port unless there is a good reason not to; and use good
> judgment. :)  I'll be looking at most changes that go into 0.94.
>
>
> Also, please do not assume that 0.96 is planned as an unstable release.
> That is not the case at all. It just might take a while to stabilize.
>
>
> This is just off the top of my head, and as usual just my $0.02.
>
>
> -- Lars
>
>
>
> ________________________________
> From: Enis Söztutar <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Monday, August 20, 2012 11:16 AM
> Subject: Porting policy from 0.96+ to 0.94
>
> Hi,
>
> Last time we were talking Lars (H.) raised the issue that we might need a
> stable base while 0.96, and its successors are fully baked in for
> production use. So, it seems that 0.94 branch releases will be a deployment
> target for some time at least on some of the organizations for some time.
> We have been backporting a lot of stuff already from trunk into 0.94, but I
> want to discuss whether  we should establish an "official" policy of what
> should be backported or not. We will definitely want bug fixes in,  but
> what about new UI stuff, or integration tests, etc. If we can agree on
> general guidelines at least, it will be then easier to decide on a
> patch-by-patch basis. What do you guys think?
>
> Enis
>
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