> except the new IPCA tree has decided to use different names for a couple of > those, hint hint... do we actually want a consistent tree structure? or is > that just being too pedantic?)
Hi Mats, saw the hints on IPCA directory. That might be the case when it moved from Service to Resource. Which directory names were you referring to? -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Mats Wichmann Sent: Thursday, April 6, 2017 1:46 PM To: Dave Thaler <dthaler at microsoft.com>; Gregg Reynolds <dev at mobileink.com>; Daniel Mihai <Daniel.Mihai at microsoft.com> Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Public and Experimental Public C APIs On 04/06/2017 02:27 PM, Dave Thaler wrote: > Well not having experimental stuff in the main branch would be a change to > current practice as there?s lots of stuff today that I would claim is > experimental. > I would have no objection to such a change, but it might be hard to get > others to agree with it. > > From: Gregg Reynolds [mailto:dev at mobileink.com] > Sent: Thursday, April 6, 2017 12:47 PM > To: Daniel Mihai <Daniel.Mihai at microsoft.com> > Cc: uzchoi at samsung.com; Dave Thaler <dthaler at microsoft.com>; > iotivity-dev at lists.iotivity.org; Mats Wichmann <mats at wichmann.us> > 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. I seem to be missing some of this thread, but... I don't mind a structure that makes it clear what's a "stable" API and what's not, that's great, assuming we're ready to declare anything "stable" at this moment. It's just it all continues to be confusing to me. It you put some code into a new area, let's say I've decided to propose a new directory resource/cloudfoo, and underneath that I've made directories include, examples, src and unittests. That's moderately consistent with what we have elsewhere (except the new IPCA tree has decided to use different names for a couple of those, hint hint... do we actually want a consistent tree structure? or is that just being too pedantic?) Now... when I set up the code in examples/, do I expect those examples to be copied to out/ and built there? Or do I expect to build them in place? If I'm building in place, I'm going to use -I./includes and put /#include "newheader.h"/ in my source files. But if I'm copying to out/ and building there, I have to place my new headers into an experimental subdirectory and put /#include "experimental/newheader.h"/ into the source files? _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&data=02%7C01%7Cstjong%40exchange.microsoft.com%7C7e7bbaad0902480fa67408d47d2df757%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636271083747377946&sdata=w%2BrQKYnLV9l%2BMmYT%2Bna67ww7qSS7u97Ig9QCYOXtvP4%3D&reserved=0
