accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Backporting features
Date Wed, 22 May 2013 18:59:19 GMT

  I read all the feedback and its much appreciated. It sounds like we don't have a concensus,
so I'm not sure how to proceed. It would be nice to say that the backporting features policy
is either allowed, disallowed, or on a case-by-case basis. If not allowed and we have long
release cycles then we likely run into the case where alternate distributions will pop up
with the features backported. Is there a way to have a clean bug fix only version and an "unclean"
version. For example , 1.5.1 and 1.5.1-with-features. 

----- Original Message -----

From: "Keith Turner" <> 
Sent: Wednesday, May 22, 2013 11:07:59 AM 
Subject: Re: Backporting features 

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