hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: State of 0.94
Date Sun, 13 Apr 2014 18:45:26 GMT
On Sat, Apr 12, 2014 at 9:56 PM, Stack <stack@duboce.net> wrote:

> > If you create a patch for any branch please consider whether it is
> > applicable to the older branches.
> +1
> Ditto for 0.96.x.  The 0.96.x branch is wide open when it comes to critical
> bug fix or test stabilization changes.

And 0.98 also, which is very close to trunk still in many respects so
porting issues are minimal.

Having three active release branches leads to some extra burden on
committers, no doubt, but I personally have found it has not required more
than a couple extra hours to patch 0.96 and 0.94 in addition to 0.98/trunk,
plus the round-trip-time of polite pings on JIRA to Stack and Lars as RMs
of the respective branches.

As for deciding when to consider other branches for a change, I use the
following rules of thumb. They might be helpful to you.

- A Test JIRA, testing tool, or integration test framework change -> Sync
all branches as closely as possible. Otherwise sorting out differences and
improvements between the branches will drive you mad. And, bugs latent in
earlier releases may well remain so unless new test cases are ported back.

- A Bug JIRA -> Assume all branches are affected, prove which ones are not,
apply to all others

- An Improvement JIRA -> Stack has said he prefers improvements not go into
0.96, and we can't have a feature discontinuity, so that precludes 0.94 as
well, so trunk and 0.98.

- A New Feature JIRA -> Trunk first, then consider backport to 0.98 on a
case by case basis. Ping the RM. (I get to short circuit that last step :-)

- An Improvement JIRA for a trunk-only feature -> Trunk only

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

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