Hi Greg, I believe most of these issues are from extlib library dependency. Currently some of external library is referring the latest version which is not originally allowed. It happen due to the different lifecycle from external library and iotivity. Sometime IoTivity requires immediate update on outside library without tag which may break the build later. I think who refers external library should maintained the script code to align the specific tag, and build system maintainer should monitor this activity.
Currently, IoTivity requires build system maintainer who cares overall build issues. It has been discussed in the ISG meeting. Agreed that it is required. We only need the volunteer. BR, Uze Choi -----Original Message----- From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of Mats Wichmann Sent: Monday, November 21, 2016 8:50 AM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] 1.2.0 build failure On 11/20/2016 03:57 PM, Nivedita Singhvi wrote: > On 11/20/2016 11:51 AM, Heldt-Sheller, Nathan wrote: >> Hi Gregg, Nivedita, >> > > Thanks for the response, Nathan. > >> I ran into the same build issue yesterday. IoTivity 1.2.0 worked >> without issues when it was released. But it looks like the update to >> TinyCBOR since then has broken the 1.2.0 release. As Kevin pointed >> out, >> 1.2.0 release requires v0.3.2 of TinyCBOR. >> >> >> >> This seems to be a problem with our build script and/or release >> process resolving dependencies on external repos (rather than an >> issue of low-quality or untested releases!). Hopefully someone with >> better > > Agreed, and as I commented earlier, there are steps one can take if a > code release breaks after it has been released. This would ordinarily > be a non-issue, just one of many trivial bugs in the development of a > sw project, if it were addressed so that it would not continue to trip > up people. > > What baffles me is why the failure to do even trivial things so that > it doesn't continue to bite others, and the assumptions that users can > just move on to current git and manually download whatever's needed. > Some of us are automating the pull and build process at our end, so > scripts which see some msg like that are going to fail. I've been through this on multiple projects. From the SCM perspective, the things called releases have to be reliably reproducible, at any time in the future - that means no pulls from version control trees (even with a tag, tags might change). If there's a problem with availability of upstream dependency release tarballs (and believe me, that happens), you need to either find a reliable mirror, or get permission to mirror those tarballs yourself. _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
