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" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Wednesday, May 22, 2013 11:07:59 AM
Subject: Re: Backporting features
On Tue, May 21, 2013 at 9:52 PM, <[EMAIL PROTECTED]> 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.
> -- 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.