hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lars hofhansl <lhofha...@yahoo.com>
Subject Re: Porting policy from 0.96+ to 0.94
Date Mon, 20 Aug 2012 20:56:14 GMT
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 <enis@hortonworks.com>
To: hbase-dev@hadoop.apache.org 
Sent: Monday, August 20, 2012 11:16 AM
Subject: Porting policy from 0.96+ to 0.94

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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message