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, <[email protected]> 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" <[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. > > 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 >
