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.
