Hi Wolodja, It's useful to note that you can use the currently preferred fixed version specifiers and still have your dependencies and the top-level project depend on multiple versions of a library (the common case is multiple versions of Clojure specified as dependencies).
Also, you can specify a baseline version requirement in project.clj and then still specify tests for your library including alternative version sets; that makes explicit what has been tested and what simply "might" work. Apart from noting the above, I have to say I simply don't see the benefit of version ranges. Here's a bunch of comments on the list of positive effects: On 4 March 2013 13:00, Wolodja Wentland <babi...@gmail.com> wrote: > I think this would have the following positive effects: > > * Projects don't have to constantly monitor new releases of new libraries > and bug authors of libraries they use to do the same That is true today in the sense that if your code works now, it will continue to work regardless of which libraries release new versions, as long as you don't change your :dependencies in project.clj or the equivalent for your build tool. On the other hand, if you care about securing your project, pulling in the latest bugfixes etc., you will need to monitor new releases anyway, regardless of the version numbering scheme used by their maintainers. > * Library authors would be more concerned about providing a stable > interface for all releases that fall into a certain version span Those library authors who care about this already act in this way. > * Packaging software and tools by downstream distributions (e.g. Debian, > Ubuntu, …), so that Clojure software can be easily used by people that > are /not/ familiar with Clojure can still easily use software written in > it, would be much easier. Are people actually using package managers for Java libraries and applications much, beyond a small number of special cases like LibreOffice (which therefore can totally be packaged überjar-like)? > * Deployment would be more predictable as people know that they target > only "stable" releases. In the absence of version ranges, that seems to be true today...? > I know that I am coming from a different culture than the "Let's package > everything in a jar and it is good", but I believe that there is merit in > stabilizing APIs and in relying on libraries that honour this. I am also aware > that my experience with Python's "batteries included", Haskell's "platform", > C's SONAMEs or Debian's packaging system might have spoiled me, but still ... Here's a relevant link to a post on Yesod's blog from April 2012 (one of top Haskell web frameworks): http://www.yesodweb.com/blog/2012/04/cabal-meta And here's an interesting quote (again, this is from Yesod's own blog): "Even with all these tools, one day I found myself completely incapable of installng Yesod from source." I know Cabal is improving and it actually has a shot at solving some truly interesting problems with dependency handling, but right now I find it surprising that one could feel "spoiled" by using it to the point of feeling discomfort in Clojure land. (We actually have it simpler for example in that we don't have to deal much with assumptions baked into previously compiled artefacts; I'm not knocking Cabal here in any way, just noting that it's not all that rosy.) > It is up to a community to fix things that are broken in their toolset and "Do > not use version ranges" is IMHO the wrong answer. There's value in using Maven simply for the easy interop with the vast Java ecosystem behind it. Maven's (Aether's?) handling of version ranges appears to be counterintuitive. I'm not sure to which degree this can be fixed on the Leiningen / Pomegranate side, but if we do expend effort fixing that, what can we expect to get in return? Cheers, Michał > -- > Wolodja <babi...@gmail.com> > > 4096R/CAF14EFC > 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC -- -- 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.
