On Mar 4, 2013, at 9:01 AM, Meikel Brandmeyer (kotarak) wrote: > Hi Chas, > > Am Montag, 4. März 2013 14:33:29 UTC+1 schrieb Chas Emerick: > There are a lot of reasons for this, but #1 for me is that few people > understand the implications of version ranges, either downstream of their > published libraries or when they are consuming a library and place a range > around its resolution. If you do, and your team does, then by all means, go > hog-wild with version ranges in your in-house libraries and applications, > where you can control versioning schemes, correspondences between APIs and > versions, and so on. However, none of those standards apply in the commons, > so ranges like the one that provoked the problem in this case > ([org.clojure/clojure "[1.2,1.5)"]) are counterproductive (i.e. there is no > reason to prospectively exclude an unreleased version unless you're certain > that API changes will break the library in question). Granted, the fallback > resolution of the Leiningen/Pomegranate/Aether triad fall down badly, which > exacerbates the problem; again, that's being worked on, but the solution > still won't help in this situation where a library blocks out e.g. 1.5.0, but > a downstream user/library explicitly specifies 1.5.0. > > Ok. So instead of the range I specify "[org.clojure/clojure "1.2"]". What > does that mean? Now I either excluded *all* clojure versions not= 1.2 or the > version number doesn't mean anything. Then we should get rid of it completely > and just specify the dependency without it. (It seems there maven poms which > do exactly that? o.O) > > The range [1.2;1.5) means that the library was tested with 1.2 up to 1.4 and > - believing in semver - their patchlevel children. 1.5 (was at that time) not > released, yet. So compatibility couldn't be guaranteed. For me this is a > reasonable approach. Sure. It might work with 1.5. Everyone is free to place > an exclusion to help the system resolve the conflict. But you must be aware > you might run into trouble. > > If I follow your approach I must provide 4 branches of a library which > basically consists of a single function: one branch per supported clojure > version (so far). This is ridiculous. Or - as I said - we let all hope go and > don't specify the version, only the dependency on the library itself. > > I see we have a different basic idea of what a version range should mean. For > me it's a promise that my library will work with the versions specified. If > one wants to use a version outside the range, that *might* be ok, but one > should be aware and pointed to that fact and the decision to do so should be > explicit! > > I'm probably just a pessimist, while you are an optimist.
AFAICT, the vast majority of Leiningen users (same goes for Maven users as well) expect the dependency vector [org.clojure/clojure "1.2.0"] to establish a lower bound, the equivalent of "[1.2.0,)". Further, people expect the maximum of all overlapping requirements to be taken (so transitive dependencies requiring e.g. "1.2.0", "1.3.0", and "1.4.0" would resolve to "1.4.0"), and for the dependencies specified in the root of the tree (i.e. the current project.clj) to override everything else, so specifying "1.3.1" in the current project would be the equivalent of "[1.3.1]" (this is equivalent to having implicit dependencyManagement in Maven, for those that know/care what that means). That's just my personal observation, but others that have done work in this area seem to agree on the general outline. Further, it *should* be compatible with the existing Aether/Maven ecosystem that we're playing in; there, bare version numbers are purely advisory, so constraining them to set a lower bound is sane. We'll see what happens when such a dependency resolution scheme is tested against the current defaults. Re: what version numbers *should* mean, etc., at least when it comes to publicly-published libraries: I don't think it's a matter of optimism vs. pessimism. A minor point is that, if you release a library with a constraint of [1.2.0,1.5.0), then to get an updated version that has an updated constraint, users may (will inevitably) have to swallow API or semantic changes that are orthogonal to the notion of "tested with". More importantly, users of libraries are always going to upgrade their dependencies faster than those dependencies' authors can qualify new releases against *their* dependencies. Indeed, given the way things work these days, projects constantly rely upon others' rarely-maintained work: people's interests and priorities shift, but if their libraries continue to work, then requiring everyone else to either wait for a new release (and for all intervening transitive dependencies to update accordingly) or manually override version ranges is counterproductive. Signal re: breakage caused by some version X of a library will always propagate faster (and probably more accurately) by users bumping into things than by a careful author validating correctness. See how it's worked in the current case: as active as you are in the Clojure community Meikel, your users have outpaced you. The same happens to all of us, all the time. :-) I agree that some indication of which libraries have been tested with which dependencies would be *great*. But that's part of a wide class of verification objectives I think that must be totally separate use cases from the (relatively) simple dependency resolution one that version numbers aim to support. Cheers, - Chas -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
