On Mon, Mar 04, 2013 at 15:04 +0100, Michał Marczyk wrote: > 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.
And then release a new version for every new release of one of my depedencies? > > * 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. Exactly and I would like to take advantage of this. I also think that establishing reasonable versioning and using version ranges as the norm would increase the pressure to, well, adhere to the norm by making sure that one does not break backward compatibility in a minor release. > > * 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)? Yes, a lot of people don't really care in which language a tool is written (nor should they) and simply want to install that software using their preferred packaging system. One reason for the need to not ship the same library all over again and in using version ranges is one of security. Imagine if a library is found to be buggy in version 1.2.3 and that a bugfix is available in 1.2.4. In order to take advantage of this one can either upgrade that single library on a system and /all other/ applications and libraries using this would be patched immediately or you could force every consumer to change their dependency on 1.2.3 to 1.2.4 and release a new version. > > * 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...? Yes, it is. But then, the environment changes (see above), whereas some of your assumptions about it might not. To give an example: I could write code against the standard library that ships with Python 2.7. I would expect that my code runs with all releases in the 2.7.* version range and would like to express that. See, for example, http://www.python.org/dev/peps/pep-0426/#version-scheme for a relevant PEP in the Python community and I am sure you'll find many other examples for other languages. > 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.) Fair enough :) -- Wolodja <babi...@gmail.com> 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
signature.asc
Description: Digital signature
