accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <>
Subject Re: Backporting features
Date Wed, 22 May 2013 15:07:59 GMT
On Tue, May 21, 2013 at 9:52 PM, <> wrote:

> Not sure if this has been decided already or not. Is there an official
> position on whether the 1.5 branch is feature frozen (and bug fixes only)
> when 1.5.0 is released? I'm finishing up ACCUMULO-1399 which I have been
> writing and testing against 1.6. I'd like to also backport to a 1.5.1.
> Thoughts?
> -- Dave

I am generally opposed to this for the following reasons.

1. Causes confusion for application that build on top of Accumulo.
 Consider the following.

 * Application W requires Accumulo 1.4.6 or later OR 1.5.2 or later.
 * Application X requires Accumulo 1.4.4 or later OR 1.5.1 or later.
 * Application Y requires Accumulo 1.4.5 or later OR 1.5.1 or later.
 * Application Z requires Accumulo 1.4.0 or later of 1.5.0 or later.

Is the above desirable?  This is what will happen if what used to be bug
fix releases turn into new feature releases.   It gets even more confusing
when there are multiple levels of indirection.

 * Application A requires Gora 3.0 which requires Accumulo 1.4.6 or later
or 1.5.1 or later.  Application A also requires a laundry list of of other
dependencies.  You could easily see a situation where someone trying to
install Application A spenda a lot of time trying to figure out why it does
not work because they are running Accumulo 1.4.4.

2. Takes time away from developing new features.  I have spent a lot of
time keeping the proxy and MAC in sync in 1.4.

3. Has the potential to introduce new bugs.

4. I think its nice to take the time to kick the tires or new features.
Which our current model gives us.  Usually we have feature freeze, and then
a month or two of beating on all of the new features in a release.  If new
features are immediately back ported, you lose this important time.  For
most of the features I have worked on, important refinements have happened
during this time.

5. Similar to point 4 maybe even the same. By realeasing new features
whenever,  you loose opportunities to make multiple new features work
together as a cohesive whole.  For example if feature M and N are slated
for 1.6.0, if M is implemented first and immediately released in 1.5.3, you
loose the opportunity to easily make needed refinements to M as N is
developed.  As with Accumulo and Map Reduce, there are efficiencies to be
gained from batching operations.

I think instead of taking this approach, we should stick to feature and bug
fix releases.  We should get our feature relases out more frequently.
 1.5.0 took way too long.  We should try to do better w/ 1.6.0.  I suspect
part of the reason people want to add new features to bug fix releases is
because 1.5.0 took so long.


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