I agree, the system is flawed as it relies upon the original developer. But because IMHO we should be considering a build-from-source approach (like python, unlike Java) it is also easy to fix - just create a fork with the changes you want. Certainly that is what we do with quite a few libraries that we use at work (minor changes but still crucial to work with our software). Of course that doesn't work for binary software, but I don't think any solution can really address that well.
I wonder if there is appetite for an API compatibility tool that scans your upgraded library versions and warns you when the public api has changed? Obviously in the Java world you just upgrade and run your test suite + the compiler to do that. Also, isn't the rust crate metadata sufficiently rich to encode at least a subset of the public api reliably? (I'm not sure) On Fri, Jan 31, 2014 at 8:32 PM, Kevin Ballard <[email protected]> wrote: > On Jan 31, 2014, at 12:23 PM, Vladimir Lushnikov < > [email protected]> wrote: > > There are some very interesting questions being raised here. I think I can > add to the discussion: > > [A] The problem of each version being in its own namespace can be solved > by "slots" (at least that's what portage calls them). See > http://devmanual.gentoo.org/general-concepts/slotting/ > > Basically you allow package authors to specify versions where there the > ABI doesn't change (I think this is completely orthogonal to the hashing of > library symbols etc) and versions where the ABI does change. So if you care > about a particular version in your rust lib, you can specify either a > version (1.0 > version and version < 2.0 if you want something more than > 1.0 but less than 2.0) or a slot or both. > > So the algorithm can still be a variant of top sort, just taking the > additional constraint of (optional) slots into account. > > > I don't know how much of an issue this is in practice, but such a system > has two flaws that I can see: > > 1) It relies on the library author correctly identifying when they've made > an API change. Any mistakes on their part will lead to problems down the > line for customers. > > 2) Even non-API changes are sometimes important to customers. Notably, bug > fixes, especially if they break previously-implemented workarounds. > > -Kevin >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
