Let's say we have multiple versions of a package installed: a-1.0 a-1.0.1 a-1.1 a-2.0 and that we have the following Build-Depends in a package description: Build-Depends: a >= 1.0 Now, when I configure, Cabal will choose a-2.0 as the package to build with. However, it makes more sense to choose a-1.0 by default instead. * Currently, if we change the program to require a feature that is in a-2.0, but not in a-1.0, then the build will succeed for _us_, but it will fail unexpectedly for someone else that has only a-1.0. However, if Cabal instead chose the minimum version available, then, _our_ build would fail, and we would know that we need to either remove the dependency on the a-2.0 feature or increase the version specified in Build-depends. * a-2.0 is not guarenteed to be 100% backwards-compatible with a-1.0. Even a-1.0.1 is not guarenteed to be backwards-compatible. So, if the original author was really testing with a-1.0, then we are more likely to run into problems with a-2.0 (or even a-1.0.1) than a-1.0. We might say that a-1.0.1 is probably a bugfix for a-1.0 that does not change the API for the package. But, we can only guess about that; maybe a-1.1 is a bugfix release too, but probably not. Furthermore, it might be the case that the library/program in question is not affected by the bugs in a-1.0, in which case it is okay to use a-1.0 even if a-1.0.1 is available. And, if it is affected, then the Build-depends should be changed to a >= 1.0.1 anyway. Practically, a package author will often want his package to work with the minimum versions of its dependencies AND the maximum versions at the same time. To support this, we might want to add a flag to "configure" that says "choose the maximum versions instead of the minimum versions" which would result in the the current behavior. This would allow the package author to build and test his package twice, once with its minimum dependencies (by omitting the flag), and once with the latest versions (by including the flag). - Brian