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. How do we judge whether user impact is high? 1) The deprecated APIs are ones that have been used for examples/are in documentation/are "recommended" in one way or another. AND/OR 2) The deprecated APIs have been present for 3 or more release cycles (and therefore have a reasonable probability of having been used in user applications). Given these conditions, a 2-3 release cycle "grace period" for deprecated APIs that subjectively satisfy them seems prudent. For "accidents" that can happen as a result of rapid development (an API that was added for one release cycle, and was not "widely advertised") - a much shorter "grace period" may be OK (perhaps even no grace period at all - but I'm not necessarily advocating for that). The presumption is that the "accidents" will be infrequent, and quickly caught (if they were not resolved during the review on the list). Best, Victor -- Victor J. Orlikowski <> vjo@[cs.]duke.edu ------------------------------------------------------------------------------ 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
