On Mon, Mar 04, 2013 at 08:33 -0500, Chas Emerick wrote: > FWIW, contributors to Pomegranate and Leiningen are working on general > solutions to this sort of madness, but the use of version ranges will always > be > largely unwarranted, especially in published libraries.
> 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.
I can not really agree with this as there are also a lot of authors of
libraries who do take versioning serious and who wouldn't, for example, break
API compatibility in a minor version. (e.g. between X.Y.Z and X.Y.Z+1 or even
X.Y+1). It would be wonderful if I, as a consumer or that library, could
simply state that my code works with all versions in the X.* version range
(but for example that it is not expected to work with X+1.*).
The specification of dependencies has to be done on a per-library basis and
will, naturally, take the versioning scheme of the specific library into
account. If I know that I can trust the author of the library to /not/ break
API compatibility in future minor releases I want to express that. I might
have even tested my code against a specific version range and want to
communicate that.
I think that the ability to specify ranges like this would actually increase
pressure to adhere to reasonable versioning schemes and, ultimately, even
better code in the community. (Simply because downstream consumers would
complain bitterly about API changes in minor releases that break their code).
> 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).
I agree completely that it does not make sense to proactively /exclude/ a
specific unreleased version from being used, but it also doesn't make sense to
depend on *one* very specific version. It is also ridiculous that there is no
differentiation between release candidates and proper releases, but that is,
yet, another can of worms.
Things that most commonly have to be expressed are. for example, the
following:
* I need at least version 1.4 to work correctly and I know that everything
older than 2.0 won't work
* My library wraps the 3.* range of releases of the Java library
foo-to-be-wrapped and I have enough test cases to be sure of that
…
I would love if I wouldn't have to start every week with running "lein outdated"
and then guessing which of the libraries can be updated without breaking
something. I want my code to simply run on the newest version of the libraries
that I (and their upstream) support. If one of those versions breaks my code
that would be bug that has to be fixed.
I am well aware that the current toolset is not ideal for these situations and
that this is also a bit of a culture clash, but there is nothing inherently
wrong with being able to specify versions in a more expressive way. The
current toolset might not be ideal, but that is a problem of the toolset and
the way software is being distributed, not with the scheme itself.
--
Wolodja <babi...@gmail.com>
4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
signature.asc
Description: Digital signature
