accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: Backporting features
Date Wed, 22 May 2013 19:16:30 GMT
I like Keith's logic. One other point I would like to make is that
backporting features lengthens the amount of time between major releases
because it diminishes the returns. Personally, I would love to see new
major releases done at least twice a year, not once.


On Wed, May 22, 2013 at 2:59 PM, <dlmarion@comcast.net> wrote:

>
>
>   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" <keith@deenlo.com>
> To: dev@accumulo.apache.org
> Sent: Wednesday, May 22, 2013 11:07:59 AM
> Subject: Re: Backporting features
>
> 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
>

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