Ari Meyer <[email protected]> writes: > Matthias, WADR, your statement seems, at least on the surface, to indicate > an incredibly fragile process. How can you possibly maintain stability and > reproducibility if the dependencies can be changed at will?
I can understand how you would say this, but I find your statement odd from an open source development norms viewpoint. It is entirely typical for a project to specify a list of dependencies with a miniumu version (because of API changes), with the notion that if built against that version or later, all will be ok. That leads to the application being judged buggy, if it doesn't cope, and the dependency being judged buggy, if it doesn't meet the interface specification. Certainly hard-core testing will be against particular versions. The history of open source projects is that usually things are ok with this fuzzy >= binding. In my little corner, qgis makes releases, and they are built within pkgsrc, which means against whatever version is in pkgsrc that minute. Aside from upstream instability of some packages, this is mostly ok. I have only been using qgis the last month or two, but have been lurking and thinking about packaging for much longer. I am curious how many documented cases of incompatibilitiies due to versions of something -- when the qgis build says both are acceptable -- there have been, and if in hindsight the bug is in qgis or the dependency. _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
