On Mon, Mar 4, 2013 at 2:01 PM, Meikel Brandmeyer (kotarak) <m...@kotka.de>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) > (Disclaimer - I'm no Maven expert) "1.2" in this case is a "soft" dependency on 1.2. This is probably what you want. < http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges > This differs from "[1.2,1.5)", which is a hard dependency of 1.2 <= ver < 1.5 I don't know the exact details, but a soft dependency basically means, that the library would like 1.2, but if something else ends up requiring 1.3 or something, then that will be ok. This way the top-level application can ultimately decide which versions are included. This seems to be the most flexible, and repeatable option. Version ranges aren't for communicating what versions of libraries you have tested against - that is best done out-of-band. If you include a version range, like the one above, you are saying that you want the software to fail to build if something ends up requiring 1.5. This probably isn't useful, as it will just lead to difficult to fix problems for library consumers. I guess the only time you might want a maximum version to be specified, is if that version exists, and is known to be incompatible with your library. -- -- 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.
