Inline [geo] From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Gregg Reynolds Sent: Thursday, April 6, 2017 12:47 PM To: Daniel Mihai <Daniel.Mihai at microsoft.com> Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Public and Experimental Public C APIs
On Apr 6, 2017 2:09 PM, "Daniel Mihai via iotivity-dev" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> wrote: Should we start with the following definitions? 1. All C functions included under out/<path_to_IoTivity_SDK>/ are Public APIs 2. All C functions included under out/<path_to_IoTivity_SDK>/experimental/ are Experimental Public APIs wait. the reason we have things like git is because it allows to avoid this sort of thing (among other things). the main branch should _never_ include experimental stuff, IMHO. that's what branches are for. [geo] problem with working on the experimental api?s in a branch is you never get other developers to try that code. You may be working on assumptions that just are not true. Moving from a branch to a master while still labeling it as experimental has a lot of value. Being on master should indicate that the code will run ?mostly? bug free. In this case experimental is being used to indicate a level of maturity, i.e. it?s a new feature that may need changing once it been used in a few really world applications. It also allows API breaking changes without a long deprecation process. At least this is the way that I see it being proposed. Maybe I am the one miss reading. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170406/a1f90e4c/attachment.html>
