Hi Iwamoto-San,
On 2016年12月15日 14:31, IWAMOTO Toshihiro wrote:
> At Wed, 14 Dec 2016 16:26:48 +0900,
> Iwase Yusuke wrote:
>>
>> Hi,
>>
>> On 2016年12月14日 15:28, FUJITA Tomonori wrote:
>>> On Mon, 12 Dec 2016 12:57:02 -0500
>>> "Victor J. Orlikowski" <v...@duke.edu> wrote:
>>>
>>>> On Mon, Dec 12, 2016, at 11:21 AM, IWAMOTO Toshihiro wrote:
>>>>> For maintaining API compatibility, having one or two release cycles of
>>>>> deprecation period, which raises warning messages if deprecated APIs
>>>>> are used, will help users. OTOH, deprecation cycles slow down
>>>>> depelopment and I am not aware of which policy ryu should take.
>>>>>
>>>>
>>>> Agreed, given that I have run afoul of this before.
>>>>
>>>> I think Fujita-San should give some guidance here, but, in my
>>>> opinion, APIs that are deprecated should probably be maintained for
>>>> *up to* 2-3 release cycles, based on degree of user impact.
>>>
>>> Thanks for the comments, guys.
>>>
>>> Seems that the project reached the stage where the developers can't
>>> break the APIs for fun. ;)
>>>
>>> As you guys suggested, having deprecation period sounds
>>> reasonable. Let's experiment 3 release cycles of deprecation period.
>>> I guess that we could have some exceptions like deleting an API that
>>> was added by mistake. Let's see how this would work.
>>
>> Just an idea...
>> for users warning, how about implementing "@deprecated" decorator
>> as following?
>>
>> File: ryu/utils.py
>>
>> def deprecated(func):
>> """
>> Decorator for marking function as deprecated.
>>
>> The decorated function should be removed in 2-3 release cycles.
>> """
>>
>> @functools.wraps(func)
>> def wrapper(*args, **kwargs):
>> LOG.warning("Called deprecated function: %s\n"
>> "This function will be remove in 2-3 release cycles.",
>> func.__name__)
>> return func(*args, **kwargs)
>>
>> return wrapper
>>
>>
>> Usage:
>>>>> from ryu.utils import deprecated
>>>>> @deprecated
>> ... def func(a, b):
>> ... print(a+b)
>> ...
>>>>> func(1, 2)
>> 3
>> Called deprecated function: func
>> This function will be remove in 2-3 release cycles.
>
> This should be ok if you are actually deprecating a function.
>
> Or, OpenStack has some decorator for semantics changes within a
> function.
>
> http://git.openstack.org/cgit/openstack/debtcollector/tree/debtcollector/updating.py
>
> Another option: for example, in this case, you could have kept the
> neighbor_add method and added neighbor_add_v2, but that's ugly.
>
> Something similar to the above listed would probably do, but it seems
> we need to devise deprecation method/procedure when a such problem
> arises in future.
Thank you for advice.
Then, it means that we need to implement appropriate warnings for its
purpose (deprecating, changing, renaming, ...).
Thanks,
Iwase
>
> --
> IWAMOTO Toshihiro
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Ryu-devel mailing list
> Ryu-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ryu-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
