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