Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: domain of josh.elser@gmail.com
 designates 209.85.128.47 as permitted sender)
Message-ID: <519CE377.2050901@gmail.com>
Date: Wed, 22 May 2013 11:25:43 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: Backporting features
References: 
 <1441173366.2325990.1369187568061.JavaMail.root@sz0053a.westchester.pa.mail.comcast.net>
 <CAGUtCHrqP6Kx+XE1M97uVs75+YA6+uRbvK6HQw+KUYcXx1087w@mail.gmail.com>
In-Reply-To: 
 <CAGUtCHrqP6Kx+XE1M97uVs75+YA6+uRbvK6HQw+KUYcXx1087w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I will point out, the argument about additional effort to backport 
changes in analogous to creating a new feature in an earlier version and 
having to merge it more recent versions.

We typically don't have the latter because new features are never 
(haven't previously?) added to a major release. Personally, I don't have 
a problem if an application needs to depend on a new minor release for 
some new capability, only if it would preclude some user from upgrading 
to a new minor release.

Given how tied up some groups get about not switching to new major 
releases of Accumulo, for new features that don't depend on the other 
new features which necessitated a major release in the first place, it 
seems we would pidgeon-hole people into having to upgrade to a new major 
release for something completely separate.

The other solution here, I think Christopher mentioned it, would be to 
keep it as a contrib/side-project and version it separately from "accumulo".

On 5/22/13 11:07 AM, Keith Turner wrote:
> On Tue, May 21, 2013 at 9:52 PM, <dlmarion@comcast.net> 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.
>
> Keith
>