<div dir="ltr">Yes, Greg, it would be interesting to know if this resulted in many actual incompatibilities or QGIS has managed to just be lucky.  Even if there are no API changes, implementation changes can certainly result in regressions.  I'm not sure what percentage of open-source projects still follow a ">= version X" policy for dependencies.  In the Java world, I haven't seen many specify Maven or Gradle dependencies like that (or even range-bound versioning), although they can.  The general policy that I've seen is to always specify precise dependency versions.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 1, 2020 at 8:09 PM Greg Troxel <<a href="mailto:gdt@lexort.com">gdt@lexort.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ari Meyer <<a href="mailto:ari.meyer@gmail.com" target="_blank">ari.meyer@gmail.com</a>> writes:<br>
<br>
> Matthias, WADR, your statement seems, at least on the surface, to indicate<br>
> an incredibly fragile process.  How can you possibly maintain stability and<br>
> reproducibility if the dependencies can be changed at will?<br>
<br>
I can understand how you would say this, but I find your statement odd<br>
from an open source development norms viewpoint.   It is entirely<br>
typical for a project to specify a list of dependencies with a miniumu<br>
version (because of API changes), with the notion that if built against<br>
that version or later, all will be ok.  That leads to the application<br>
being judged buggy, if it doesn't cope, and the dependency being judged<br>
buggy, if it doesn't meet the interface specification.   Certainly<br>
hard-core testing will be against particular versions.  The history of<br>
open source projects is that usually things are ok with this fuzzy >=<br>
binding.<br>
<br>
In my little corner, qgis makes releases, and they are built within<br>
pkgsrc, which means against whatever version is in pkgsrc that minute.<br>
Aside from upstream instability of some packages, this is mostly ok.<br>
<br>
I have only been using qgis the last month or two, but have been lurking<br>
and thinking about packaging for much longer.  I am curious how many<br>
documented cases of incompatibilitiies due to versions of something --<br>
when the qgis build says both are acceptable -- there have been, and if<br>
in hindsight the bug is in qgis or the dependency.<br>
</blockquote></div>