There is not only API change. Sometime, from a minor version to another, a feature get silently broken (that is silent regression). While it might not impact libA which depends on it, but it may fail libB which also depends on it, but with a previous version. As a result, libA force installation of this dependency without any concern (all its features works) but libB get broken without any concern.
And that the real mess to deal with. That's happened this week at my job... I largely prefer each library be self contained, ie, if libA depends on libZ version X.X.X, and libB depends on libZZ version Y.Y.Y, just let each one be installed and used at there own version. That is perfectly acceptable (and even recommended) for a non system integrated software (for example when a companie want to build a software with minimum system dependency that would run on any version of Ubuntu, with the only dependency on libc. On the other hand, when the software get integrated into the distribution (ubuntu, redhat, homebrew), let the distrib version manager do its job. ----- Gaetan 2014-02-01 Tony Arcieri <[email protected]>: > On Fri, Jan 31, 2014 at 4:03 PM, Lee Braiden <[email protected]> wrote: > >> This would be counterproductive. If a library cannot be upgraded to 1.9, >> or even 2.2, because some app REQUIRES 1.4, then that causes SERIOUS, >> SECURITY issues. >> > > Yes, these are exactly the types of problems I want to help solve. Many > people on this thread are talking about pinning to specific versions of > libraries. This will prevent upgrades in the event of a security problem. > > Good dependency resolvers work on constraints, not specific versions. > > The ONLY realistic way I can see to solve this, is to have all higher >> version numbers of the same package be backwards compatible, and have >> incompatible packages be DIFFERENT packages, as I mentioned before. >> >> Really, there is a contract here: an API contract. > > > Are you familiar with semantic versioning? > > http://semver.org/ > > Semantic Versioning would stipulate that a backwards incompatible change > in an API would necessitate a MAJOR version bump. This indicates a break in > the original contract. > > Ideally if people are using multiple major versions of the same package, > and a security vulnerability is discovered which affects all versions of a > package, that the package maintainers release a hotfix for all major > versions. > > -- > Tony Arcieri > > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
