Am 19.01.2016 um 14:35 schrieb Ingo Weinhold:
On 01/19/2016 01:26 PM, Stephan Aßmus wrote:
Am 19.01.2016 um 11:41 schrieb Ingo Weinhold:
On 01/18/2016 04:26 PM, Simon Taylor wrote:
This sort of fragility is a bit of a shame - essentially it prevents
updating library packages until any packages that use them have been
built against the updated version.
Packages can codify their required version range.
How would that work? When you build your package, you link against the
newest version of some lib. And that is also what you tested with. So
usually you would declare your package to depend on the version of the
library that you build and tested with "or newer". Only when a newer
version of the library becomes available, it becomes clear that it is
incompatibly with old apps. You would have to rebuild the app package,
now declaring a version range with an upper limit.
The only alternative seems to be that you declare a very restrictive
version range up front. But then you condem everyone to keep an old
library version around for possibly no reason. And this problem is
multiplied when there are a couple of apps installed which each declare
depending on a slightly different version, when all those versions of
the lib are actually compatible.
I didn't mean to imply that programs should or would typically specify
an upper library version. That's a rare case e.g. when there's already a
newer library version out there and, while binary compatible, some
behavior changed in a way that makes your program unhappy. But usually,
as you wrote, you'd only specify the lowest library version. The upper
version is provided implicitly by the library packages, because they
specify their backward compatibility version.(*)(**)
