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
http://gravatar.com/ctubbsii
On Wed, Oct 8, 2014 at 8:00 PM, Christopher <[email protected]> wrote:
> On Wed, Oct 8, 2014 at 7:16 PM, dlmarion <[email protected]> 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 <
>> [email protected]> </div><div>Date:10/08/2014 6:55 PM (GMT-05:00)
>> </div><div>To: [email protected],Jeremy Kepner <[email protected]>
>> </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 <[email protected]> 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.
>> >
>>
>
>
