+1 on opt-in for BT5 although I do think there are quite a few configuration variables for features that are on by default. Not sure there is a rhyme or reason, other than possibly the thought that “most people would be enabling this, so let’s have it on by default”.
> On Apr 10, 2017, at 11:50 AM, Łukasz Rymanowski > <lukasz.rymanow...@codecoup.pl> wrote: > > Hi, > > On 10 April 2017 at 18:15, will sanfilippo <wi...@runtime.io> wrote: > >> I think #3 is fine as well. If, for some reason, folks do not want to >> claim 5.0 support they can always use release 1.0.0 of Mynewt. >> >> >> >> On Apr 10, 2017, at 6:16 AM, Szymon Janc <szymon.j...@codecoup.pl> wrote: >>> >>> Hello Community, >>> >>> We are currently upstreaming Bluetooth 5 functionality into Apache >> Mynewt. >>> Sine all of the new features are optional to support (excluding internal >>> dependencies) we could make Mynewt code configurable per feature. It >> shouldn't >>> be too much hasle to support this via syscfg.yml with MYNEWT_VALs. >>> >>> There are few possible paths and I'd like to gather some feedback. >>> >>> 1. Always claim 5.0 (LL version) support and leave all features >> configurable. >>> 2. Same as 1. but also allow to configure 4.2 vs 5.0 support. >>> 3. Same as 1. but always enable triavials (Privacy Erratas, High Duty Un- >>> Directed Advertising) and leave other features configurable. >> >> 4. Always enabled everything. >>> >>> Personnally I'd opt for 3. Mostly due to fact that it doesn't increse >> code >>> size comparing to 4.2 and reduces number of configuration variables. So >> it >>> feels to be a good compromise between configurability and complexity. >>> >> > > That looks good to me as well. > >> There is also open point of opt-in vs opt-out configruation. I think we >> should >>> go with opt-in ie. optional feature needs to be explicitly enabled in >> syscfg. >>> >> > > I think other features (e.g. LE CoC) are opt-in so we should follow that. > > >>> Comments? >>> >>> -- >>> pozdrawiam >>> Szymon Janc >> >> > Best > Łukasz
