[rust-dev] Deprecating rustpkg

Vladimir Lushnikov vladimir at slate-project.org
Fri Jan 31 16:05:46 PST 2014

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 <leebraid at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140201/cc48f486/attachment.html>

More information about the Rust-dev mailing list