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 <[email protected]> wrote: > 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
