> - our googletest is on 1.7 (the Sept. 2013 release), while upstream is on 1.8 > (Aug 2016 release). There may be reasons to stay with 1.7, I don't know the > googletest version impacts on the project
There is no reason we cannot update googletest to version 1.8. Still, continuing to use googletest version 1.7 should not impact the project in any way. So I would not place updating to the latest googletest as a really high propriety. I would agree about mbedtls, it should probably be updated to use the latest version to gain the security improvements. For the rest of the external projects I will let others with more knowledge leave there comments. George Nash -----Original Message----- From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Mats Wichmann Sent: Tuesday, March 20, 2018 9:32 AM To: IoTivity Developer List <iotivity-dev@lists.iotivity.org> Subject: [dev] extlibs and next release As iotivity moves forward, it would be good to resolve questions on versions of external projects we link to. - tinycbor was flipped to 0.5 for master so it's up to date. however, one respondent on the list (Jason Sun - sunlifeng...@haier.com) recently reported having problems because of 0.5 which went away when dropping to 0.4 - I don't know all the details since I was traveling and not paying attention. We should make sure that's rooted out. - we're still using an old internal libcoap. I fixed the problems with using the "upstream" (actually another fork, but more recent) libcoap on Linux, but there were problems on other platforms when I submitted that to gerrit. This should not be complicated. In addition, our forked "upstream" is not the latest from the upstream project. I know there are patches we need which did not go in upstream. - some of the codebase uses our own forked copy of utlist.h, some uses the one found in libcoap (that is, some files #include "utlist.h" and others #include <coap/utlist.h>). utlist.h is from another external project (uthash) so there's a sync challenge here - our forked copy is much newer than the one in the libcoap we're using and slightly newer than the "upstream" libcoap we would otherwise use (see previous note). I recall finding some location in the code that defines a couple of macros because they're convenient and found in a later upstream version, but they're actually in our copy (resource/c_common/utlist.h). - our googletest is on 1.7 (the Sept. 2013 release), while upstream is on 1.8 (Aug 2016 release). There may be reasons to stay with 1.7, I don't know the googletest version impacts on the project. - mbedtls in our tree is 2.4.2, plus our own patch. Upstream is now on 2.7.1 - there have been three version and three dot releases since the one we're using. we're out of date on other things too, the above is not an exhaustive list. the point of this message is to think about which uplifts we want and get them done before something gets into a QA cycle and it becomes more expensive quantify the impacts of a switch. it's also fine not to sync to upstreams, but it should be a conscious decision - upstreams continue evolving with features, bug fixes, and security issue that we should not just ingore because it looks like what we have is "working OK". I'd assume from a security viewpoint it would be particularly important to pay attention to mbedtls evolution. -- mats (note: my email provider made it onto the SORBS list. again. I'm going to have to pay to make a change as they seem unable to prevent this. anyway: I changed my iotivity subscription to an unaffected address to avoid bounces, but this is only supposed to be a temporary change - it's still me even if you may not recognize the address) _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
