accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Deprecation removal for 1.7.0
Date Thu, 09 Oct 2014 00:08:50 GMT
Okay, so from this conversation, I've got a path forward to remove stuff
deprecated in 1.x in 2.x only (not in 1.7), including aggregators, since
this is the most conservative action.

I'm still a little uncertain about the resolution for
Instance.{set,get}Configuration() as an exception, but rather than pursue a
vote or risk a veto on a patch, what I think I've decided to do for that,
is simply remove all uses of it (again) internally, and provide stronger
javadoc messages deterring its use.

Thanks all for the feedback.

Christopher L Tubbs II

On Wed, Oct 8, 2014 at 8:00 PM, Christopher <> wrote:

> On Wed, Oct 8, 2014 at 7:16 PM, dlmarion <> wrote:
>> Personally I think this discussion is headed in the wrong direction. I
>> would suggest picking a release numbering policy. Then, develop the
>> features for the release and adjust the release number based on the client
>> api changes caused by the changes in the release. If someone needs a
>> feature but cant afford the client api change, then try to backport it. We
>> should try to move forward.
> Certainly... and we've agreed to that idea (though not the specific
> policy) in previous conversations, starting with 2.0.0. We have not
> established that we would attempt to do this in any way for any 1.x
> releases, though it sounds like tending towards that is the general desire.
>> <div>-------- Original message --------</div><div>From: Adam Fuchs
>>> </div><div>Date:10/08/2014  6:55 PM  (GMT-05:00)
>> </div><div>To:,Jeremy Kepner <>
>> </div><div>Subject: Re: Deprecation removal for 1.7.0 </div><div>
>> </div>What's the right level of review? Should we have a public
>> announcement
>> board of some sort on the website, or is a request for comment on the
>> user list sufficient?
>> On Wed, Oct 8, 2014 at 5:35 PM, Jeremy Kepner <> wrote:
>> > Perhaps the process should be changed to require review prior to
>> deletion.
>> > We can't assume all our users are always scanning the e-mail list.
>> > It is a reasonable expectation that we won't break their code.
>> >

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