I disagree. With the same analogy, I could sell you a blunt knife - you would use it as a letter opener, and then I would fix the bug. Now you might actually cut yourself!
I think this is a different concern. It should be up to the library author what they deems as 'compatible'. It does not excuse the consumers of the library to do their own testing that it produces the results they want (a version number in any form is not a proof of correctness). On Sat, Feb 1, 2014 at 12:03 AM, Lee Braiden <leebr...@gmail.com> wrote: > On 31/01/14 23:03, Tony Arcieri wrote: > >> Can anyone point to a real-world example of a dependency resolver which >> can produce solutions which may-or-may-not contain multiple versions of the >> same library? >> > > 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. > > 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. To break compatibility > is to break that contract. This is a bug, and shouldn't happen. If you > want to make something incompatible, you simply shouldn't call it the same > name as the thing it's incompatible with. No more than you should sell a > knife as a bottle-opener. They do not fulfill the same contract, and to > say they do is false advertising. > > -- > Lee > > > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
