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, <[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
