At Thu, 15 Dec 2016 15:33:30 +0900 (JST),
FUJITA Tomonori wrote:
>
> On Thu, 15 Dec 2016 14:31:25 +0900
> IWAMOTO Toshihiro <iwam...@valinux.co.jp> 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.
>
> Just let me make sure that I don't think that adding a new argument
> like this time needs a new function. It could have kept the
> compatibility; the old code works as before.
With hindsight, enable_ipv6 could have defaulted to the previous
behavior if unset, without these deprecation warning things.
--
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
