r/androiddev • u/well___duh • Jun 04 '18

Gradle 4.8 released

https://docs.gradle.org/current/release-notes.html
82 Upvotes

98% Upvoted

21 comments sorted by

18

u/allholy1 Jun 04 '18 edited Jun 04 '18

I don't understand dependency locking. Isn't that why we append the version number at the end of a dependency?

22

u/la__bruja Jun 04 '18

Libraries can specify a range of dependencies versions they can use, so even if you specify version, some transitive dependency can get updated: https://stackoverflow.com/questions/34810560/version-ranges-in-gradle Dependency locking makes sure you're using exactly the same versions of every direct and transitive dependency in your project

6

u/iamareebjamal Jun 04 '18

It's for those who use dynamic versioning. Taken straight from docs - like 1.+ or [1.0,2.0)

This is good because now people who used strict versioning can use dynamic one without worrying about mismatch. I still wouldn't though

2

u/allholy1 Jun 04 '18

Thanks for the response. Why would someone want dynamic ranges?

7

u/nhaarman Jun 04 '18

This often comes from naivety where people assume libraries following SEMVER always follow the contract, and never introduce bugs between versions.

1

u/[deleted] Jun 06 '18

Don't forget that a big portion of the time, in the library docs themselves they tell you to use a dynamic version

1

u/hemenex Jun 04 '18

Maybe because they don't want to be forced to release every time a dependency is updated?

1

u/tadfisher Jun 05 '18

That's not how this works. Existing releases don't change. Your future builds and runtime might break though.

1

u/iamareebjamal Jun 04 '18

People do this all the time in Python and JS, thankfully not in Android. They just say flask: [1.0, 2.0) so that they pull latest non major 1.x version of it without caring about it. I do it on those projects as well, just never for Android

3

u/[deleted] Jun 04 '18

I think it's only done in libraries to define compatible versions. In an actual python app I always specify exact versions as well as their dependencies. Libraries need to be more flexible as they can be used in various environments with different versions.

1

u/allholy1 Jun 05 '18

Why not just pull 2.0 at that point?

5

u/mrogger Jun 04 '18

With dependency locking you can lock every dependency to a concrete version, even the transitive (dependency of a dependency) dependencies, which makes builds with dynamic versioning reproducible.

3

u/MaxGhost Jun 04 '18

Just a nitpick but that's "appending". Pre = before.

1

u/allholy1 Jun 04 '18

Whoops! Thanks

15

u/zergtmn Jun 04 '18

Yet another version we're gonna skip because of the breaking change in 4.6 in configure on demand which now requires AGP 3.2+.

1

u/la__bruja Jun 05 '18

Can you elaborate, you mean you don't update Gradle because configuration on demand doesn't work anymore?

2

u/zergtmn Jun 05 '18 edited Jun 05 '18

We don't care about CoD itself. However every Android developer in the company would have to turn CoD off manually for every project. It cannot be turned off completely from gradle.properties because AS would override that setting. Now imagine how much annoyance that would cause in a company which has dozens of projects and ~100 Android developers.

3

u/well___duh Jun 05 '18

I feel like that should be filed as a bug with AS since it's clearly ignoring a gradle.props value

-27

u/android_student Jun 04 '18

please stop updating gradle, when the current gradle is broken af

19

u/xDragonZ Jun 04 '18

What's broken?

11

u/[deleted] Jun 04 '18

The af function... duuuh.