The baby and the bathwater

[Cédric Champeau]

>
> They do. The fact that they create further (solvable) challenges does not
> mean that they are not a solution to the initial problem.
>
> The second point is also incorrect - indeed, this is exactly the point of
> using a range rather than a point version. If I depend on a range "[1.4,
> 2.0)", this is because I need a *feature* that was released in version 1.4
> of the dependency.
>

This is an arbitrary interpretation of a range. In practice people use them
for very different purposes. If, when you write "[1.4,2.0)", you assume
that you need a feature of 1.4, this is already an assumption. Most people
use 1.4 as the baseline because _this is the latest version available when
I started_. They also _assume_ that anything from 1.4 would work. In
practice this is rarely the case. There are bugs introduced, there are
binary incompatibilities (despite semantic versioning). Ranges are a
_convenience_, but certainly not an answer. Ranges + locking are better,
because you _have to_ test, but they don't account for the environment
either (say, my app depends on servlet-api, which version should you use?
It should be _strictly_ what the runtime environment will give).


>
> Well what does it mean when you write "compile 'foo:bar:1.0.4'" in your
> build.gradle file? It means you have compiled against that version of the
> API, and your module will be compatible with that version up to the next
> breaking change (2.0 if the dependency is using semver).
>
>
In Gradle you'd not use `compile` anymore. You would use:

api 'foo:bar:1.0.4'

for an API dependency, one that is exposed by your very own library (mostly
maps to "requires transitive")

and you'd use:

implementation 'foo:baz:2.1.4'

for an implementation dependency, that is _not_ exposed by your API (mostly
maps to "requires").

And if a transitive dependency needs a different version, we have
strategies to select a best match, or fail.


> If you wanted your module to be compatible with 1.0.3 then you would have
> compiled against 1.0.3. Unless you do that, there is no way for any tooling
> to infer that you are indeed compatible with 1.0.3.
>

That's again an over simplification. Real world apps have different
problems. You may say "1.0.3", because 1.0.2 had a bug. Maybe your app
didn't even depend on the faulty behavior, but because it had a bug, you
upgraded. And, maybe one of your dependencies actually required 1.0.2
because 1.0.3 introduced a regression. So you want to be able to downgrade
dependencies. Gradle makes it possible. There's a big difference between
the "ideal world", and the world we live in.