Home | About | Sematext search-lucene.com search-hadoop.com
 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
Enis Söztutar 2012-08-20, 23:24
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
>