Hopefully the maintainer, architect and release lead can reach consensus together. But, I agree that we need to define that process more formally.
(we could start with an ?experimental process? for this judgment, and work towards a ?non-experimental process? for the longer term ?) Dan From: ??? [mailto:uzc...@samsung.com] Sent: Friday, April 7, 2017 7:51 AM To: Daniel Mihai <Daniel.Mihai at microsoft.com> Cc: iotivity-dev at lists.iotivity.org Subject: RE: RE: [dev] Public and Experimental Public C APIs Someone should judge this API set will be guaranteed in the long run. Then maintainer should decide it or architect or release lead should decide it? BR Uze Choi --------- Original Message --------- Sender : Daniel Mihai <Daniel.Mihai at microsoft.com<mailto:Daniel.Mihai at microsoft.com>> Date : 2017-04-07 23:35 (GMT+9) Title : RE: [dev] Public and Experimental Public C APIs I look at Experimental APIs as similar to: ?Beta quality, use it only if you feel adventurous?. Non-Experimental means that the API owners are committed to fixing significant bugs in these APIs, and will try hard to not break existing callers of these APIs. We need to work towards non-Experimental status for our APIs ? otherwise many folks will not dare to develop apps on top of these APIs. Dan From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ??? Sent: Friday, April 7, 2017 7:24 AM Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] Public and Experimental Public C APIs What does `experimental` mean here? Out of OCF spec scope or not officially managed item?
