“should not vendor-specific features go in vendor-specific forks or libs? otherwise we end up with a kitchen sink o' cruft.”
Completely agree with that. Vendor-specific features should never be coded (even if #ifdef’ed) into the middle of files in the master branch, in my view. Dave From: [email protected] [mailto:[email protected]] On Behalf Of Gregg Reynolds Sent: Friday, August 18, 2017 11:54 AM To: Heldt-Sheller, Nathan <[email protected]> Cc: [email protected] Subject: Re: [dev] direct pairing On Aug 18, 2017 12:20 PM, "Heldt-Sheller, Nathan" <[email protected]<mailto:[email protected]>> wrote: Hi George, Direct Pairing wasn’t ever a Specified feature; it was a Vendor Defined feature that shouldn’t have been compiled in by default in the first place (all vendor-defined features should be conditionally compiled out by default). For Vendor Defined features, the deprecation process is up to the contributing vendor… it’s possible that code can just be removed if it’s no longer wanted by the contributing vendor, etc. should not vendor-specific features go in vendor-specific forks or libs? otherwise we end up with a kitchen sink o' cruft. As for Specified feature deprecation, IoTivity needs to draft behind the Specification’s deprecation process, which will be much more carefully monitored and agreed upon by the OCF Specification body in question. Hope that helps, Nathan From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Nash, George Sent: Thursday, August 17, 2017 5:03 PM To: Gregg Reynolds <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [dev] direct pairing I would like to know what is the process for deprecation. On past projects that I have worked on we had a clearly specified deprecation process. Once a feature or API was deprecated it was marked deprecated in the code using paragmas, markup, or whatever means was needed. If it tells the compiler its deprecated then that’s the best. Then the code would still be supported for a year. Support meant it would continue to build and pass any tests that were in place to test the code before it was deprecated. After a year it would go into non-supported mode. It would remain for at least one more release but would not have any guarantees. It would typically still build but who know what it would do beyond that. After that it could be removed at any point. Note: exceptions to the deprecation policy were made based on security concerns. I would like to see a similar policy go in for IoTivity. Since there is no deprecation policy I really don’t know how the direct pairing code should be handled. George Nash From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Gregg Reynolds Sent: Thursday, August 17, 2017 12:02 PM To: [email protected]<mailto:[email protected]> Subject: [dev] direct pairing i see direct pairing has been deprecated. is is safe to remove the direct pairing code from csdk security?
_______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
