accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Backporting features
Date Wed, 22 May 2013 02:29:24 GMT
I don't know about precedent, but...

My general opinion is that new features shouldn't be back-ported to
the main branch of older release lines, unless there's a compelling
reason. Instead, they should be supported as separate add-on that one
can compile in (perhaps as a patch in the contrib area?), or as a
forked branch.

The reason for this opinion is that it can be surprising and
disruptive for users if they end up relying on new features in a
bugfix'd version, and for whatever reason, have to switch to an
earlier version of the same release line (perhaps a bug was found in a
bug-fix, and they were forced to roll back, or they move to a system
that hasn't yet been upgraded).

A second reason for this is that back-ported features can often behave
in ways that are different from the way they behave in the branch in
which they were introduced, and this can also introduce confusion.

Of course, this is just a general opinion... any specific opinion
about a particular feature, I'd have to form on a case-by-case basis.
I think MiniAccumuloCluster, for instance, was a great thing to
backport, because of it's ability to enable testing of the core
functionality, rather than it actually modifying any core
functionality. I'm less enthusiastic about backporting the proxy, but
I can see how it could be useful, especially if it helped people
transition seamlessly to newer versions of Accumulo without re-writing
lots of utility code.

I should also mention that one of the reasons I was thinking about
git, and initiated a discussion about that today on this list, was
because I was thinking about the convenience it might provide enabling
the creation of forked branches with backported features (rather than
include them in the "official" release line)... though that particular
application of git might need further discussion (because it can be
annoying to have an excessive number of branches for backported

Christopher L Tubbs II

On Tue, May 21, 2013 at 10:04 PM,  <> wrote:
> I was using my issue as an example and was looking for a general policy from the community.
Sounds like it has already been talked about and there is a precedent.
> ----- Original Message -----
> From: "Corey Nolet" <>
> To:
> Sent: Tuesday, May 21, 2013 10:02:14 PM
> Subject: Re: Backporting features
> Maybe this is opening a can of worms- but if the proxy was backported to
> 1.4.4, I can't see why your new work shouldn't be.

View raw message