Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates
 64.18.1.31 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
Date: Tue, 19 Jun 2012 13:47:12 -0700
Subject: Re: deprecation policy
Thread-Topic: deprecation policy
Thread-Index: Ac1OXItOyNXZb4MZR4iNT67huqg7kQ==
Message-ID: <CC063350.874F%fil@adobe.com>
In-Reply-To: 
 <CADVgkyM4-5R6b2E2teH8z7YNRvwAcJz_io5f4oj1+tVtvN0CVQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.2.120421
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

This all sounds reasonable. Shall we go ahead and employ this as "the
policy" moving forward?

Does it need a vote?

On 6/19/12 12:34 PM, "Brian LeRoux" <b@brian.io> wrote:

>perhaps we put a timestamp / date of deprecation in the warning too?
>
>On Tue, Jun 19, 2012 at 2:04 PM, Bryce Curtis <curtis.bryce@gmail.com>
>wrote:
>> I agree that deprecation doesn't have to be tied to a major release,
>> but we should definitely give enough advanced notice.  6 months is
>> arbitrary, but sounds like a reasonable period.  This carries the
>> caveat that the deprecated item is documented and known so it's not a
>> surprise to developers.  So, if we consider the deprecation of "ctx"
>> in Android plugin, it probably shouldn't be removed in 2.0, but in
>> whatever release falls after Nov.  This will minimize the pain to
>> plugin developers, who are an important segment of our "customers".
>>
>> There may be instances where structural changes make it impossible to
>> maintain deprecated APIs for the entire 6 month time, but I would
>> consider this an exception and only if there's no way to maintain
>> both.
>>
>> On Mon, Jun 18, 2012 at 5:30 PM, Filip Maj <fil@adobe.com> wrote:
>>> To me version numbers are just a label. It's more about exposure,
>>> communication and documentation.
>>>
>>> If we employ the standard deprecation techniques for the native
>>>platforms
>>> enough ahead of time, blog about upcoming breaking changes, provide
>>> tutorials and documentation for how to migrate, I am fine with it.
>>>
>>> On 6/18/12 3:25 PM, "Brian LeRoux" <b@brian.io> wrote:
>>>
>>>>We don't really have one tho I think we loosely follow Semantic
>>>>Versioning. In Android-land we recently merged in CordovaView which
>>>>has an API change which will break many plugins.  In Semantic
>>>>Versioning reality we are completely justified to kill an API in 2.x
>>>>which would make a great deal of pain for plugin authors at that time.
>>>>Major release, break all the things, seems bad.
>>>>
>>>>Anyhow, I'm thinking we look to create a policy that is time based. We
>>>>make a change, its got 6 months of deprecation notices, and then its
>>>>gone, regardless of version number.
>>>>
>>>>Thoughts?
>>>