Hi Uze, One option could be: Use different API name spaces (ex OIC name space and private namespace) during the ?GAP? period. i.e. :The spec feature gets developed in the OIC namespace, the open source gets developed in a private namespace. Once the spec and open source have converged for the specific feature, plug the open source feature into the OIC API namespace. Whether (and how long) the open source (or a product) wants to maintain the private namespace (now legacy) becomes then an Iotivity (or product) choice. What?s important is that the open source allows those options (through a compile flag) so constrained devices can compile out the legacy overhead (when appropriate).
Pro: no API breaks while the feature matures (as spec and open source play in different name spaces). Con: there is still some API breakage when the private API gets dropped (but that becomes a Iotivity/product choice). This is still far from a perfect solution but may limit the interop issue you highlight... BR, S. From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of ???(Uze Choi) Sent: Thursday, 18 February, 2016 10:09 AM To: iotivity-dev at lists.iotivity.org Subject: [dev] IoTivity Backward compatibility support level issue. Hi All,
