[rust-dev] Deprecating rustpkg

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


Looking briefly over the semantic versioning page, doesn't it just mandate
a particular version format for when you break API compatibility? This is
in theory the same thing I was talking about with slots, just encoded in
the version number. It can get ridiculous as well though - see for example
openssl's version 1.0.0l…


On Sat, Feb 1, 2014 at 12:09 AM, Tony Arcieri <bascule at gmail.com> wrote:

> On Fri, Jan 31, 2014 at 4:03 PM, Lee Braiden <leebraid at gmail.com> 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
> 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/4dcbbd94/attachment.html>


More information about the Rust-dev mailing list