buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Toulme <>
Subject Re: Dependencies are naturally version ranges, not single versions
Date Sun, 09 Oct 2016 01:16:41 GMT
Thank you for taking the time to write down your thoughts.

BUILDR-274 is very much something we want to get to eventually.

Maven supports version ranges. How they do it might be different from the behavior you describe.
I need to compare both, did you by any chance look into that?

> On Oct 7, 2016, at 22:06, 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

View raw message