buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Dependencies are naturally version ranges, not single versions
Date Sun, 09 Oct 2016 09:04:53 GMT

We have talked about this problem in the past but unfortunately at the time
no one on the buildr team had the cycles to have a shot at it. Luckily
someone from the community Michael Guymon, took the idea and ran with it.
First with

but this got deprecated in favour of

I have never used it but have been quite impressed by the idea, design and
code. I think there is probably a way we could better integrate it with
Buildr if someone wanted to try and get it as the default/recommended
mechanisms in buildr but you may also be able to use it as is with little
to no friction.

I have CC'ed the developer who may want to advocate for it's use too ;)

On Sat, Oct 8, 2016 at 4:06 PM, Trejkaz <> wrote:

> Continuing from
> Let's suppose that version ranged dependencies don't exist.
> Let's also suppose that:
> * Library A depends on Library C 1.0.
> * Library B depends on Library C 1.1.
> * The changes from C 1.0 to C 1.1 were done according to semver (all
> libraries should be doing this), and therefore code written to 1.0
> will work against 1.1.
> Now suppose your application wants to depend on both A and B. Now you
> have a transitive dependency on both C 1.0 and 1.1. If you're using
> OSGi, this _may_ be okay, though there are cases where it is not - for
> instance, if two libraries are expected to pass between themselves
> objects of a class defined in a third. If you're not using OSGi or a
> similar runtime which allows running two different versions of the
> same library, now you can't run your code. If you have an application
> with a large number of dependencies, you end up having to go to
> multiple libraries and begging them to update to some minor patch
> release just so that your build can resolve the dependencies.
> The problem, as I see it, is that A doesn't _really_ depend on C 1.0.
> By definition, C 1.1 introduced backwards-compatible changes, so A
> should also work against C 1.1. _If_ A also works against C 1.1, then
> saying it depends on 1.0 is a lie. As a library developer, I would
> prefer to specify my dependencies in a way which represents what I
> actually support, even if the build only runs against one specific
> version of it. Compiling should be done against the _lowest_ version
> in the supported range, if it isn't checked against all of them.
> *Ideally*, tests should be run against all combinations of
> dependencies. I do see some projects doing this, presumably to be
> doubly-sure that their dependencies are correct.
> An an application developer and someone who wants to build the
> integrated project, I would like all libraries to declare their
> dependencies accurately, so that the build tool can reliably detect
> actual conflicts. If B suddenly starts depending on C 2.0, I want to
> know about that. But today's build tools only give me two
> unsatisfactory options:
>   (a) All your versions have to match, which they never do, so your
> build is always conflicting, and you have to manually inspect other
> people's code to see whether it will work with a newer version or not.
>   (b) Allow versions not to match, but when they clash, always pick
> the latest one, and eventually you will get some NoClassDefFoundError
> when someone accidentally updates a library which another library
> actually needed.
> Accurately specified dependencies should also not make my build
> unreproducible, as implied by the comment on the ticket. There are
> multiple reasons why:
>   1. As long as nobody is specifying open-ended version ranges, it
> shouldn't even be possible for a new incompatible version to suddenly
> break the build. You should only be specifying dependencies you have
> actually tested anyway.
>   2. If you update a library and the dependency of the updated version
> was a newer version of some other library, the build didn't break
> because of version ranges, it broke because you actually changed
> something.
>   3. Even problems of specifying open-ended version ranges have been
> solved by other dependency-resolution systems. For instance, RubyGems
> keeps a "lock" file which contains the actual versions of everything
> used last build, so the next build will use those versions until
> someone actually updates something deliberately. It seems to be
> working.
> TX


Peter Donald

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message