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.
--
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
