Lock only major version for espresso and rxjava

[fourlastor]

I believe a library shouldn't lock the minor and patch version of its dependencies. According to semantic versioning that shouldn't affect backward compatibility (I guess rxjava and the android dev team respect it).

That makes it easier for the developer to unlock a bugfix for anything being used without being blocked by the project dependencies.

[plastiv]

Please, don't. Wildcard versions undermine deterministic and hermetic builds and are generally considered bad practice.

Only single dependency is allowed to be in classpath and by default Gradle will choose dependency with a greater version number. So just specify needed version in your build file:

compile 'io.reactivex:rxjava:1.0.12'

or use force resolution mechanism from Gradle to upgrade the dependency. You are allowed to do it without touching or recompiling sources of the library.

configurations.all {
    // check dependency tree with gradlew :app:dependencies

    // avoid wildcard '+' dependencies used at 3rd libraries forcing them to exact version
    resolutionStrategy.force "io.reactivex:rxjava:1.0.12"
}

More info: https://docs.gradle.org/current/userguide/dependency_management.html

[fourlastor]

That's what I did at first, then I noticed the build failed:

Warning:Conflict with dependency 'io.reactivex:rxjava'. Resolved versions for app (1.0.12) and test app (1.0.10) differ.
:app:preBuild UP-TO-DATE
:app:preDebugBuild UP-TO-DATE
:app:checkDebugManifest
:app:preReleaseBuild UP-TO-DATE
:app:prepareComAndroidSupportAppcompatV72220Library UP-TO-DATE
:app:prepareComAndroidSupportSupportV42220Library UP-TO-DATE
:app:prepareDebugDependencies
:app:compileDebugAidl UP-TO-DATE
:app:compileDebugRenderscript UP-TO-DATE
:app:generateDebugBuildConfig UP-TO-DATE
:app:generateDebugAssets UP-TO-DATE
:app:mergeDebugAssets UP-TO-DATE
:app:generateDebugResValues UP-TO-DATE
:app:generateDebugResources UP-TO-DATE
:app:mergeDebugResources UP-TO-DATE
:app:processDebugManifest UP-TO-DATE
:app:processDebugResources UP-TO-DATE
:app:generateDebugSources UP-TO-DATE
:app:processDebugJavaRes UP-TO-DATE
:app:compileDebugJava
Note: /home/daniele/development/OneContact2/app/build/generated/source/apt/debug/com/fourlastor/onecontact/injection/DaggerApplicationComponent.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:app:compileDebugNdk UP-TO-DATE
:app:compileDebugSources
:app:preDebugAndroidTestBuild UP-TO-DATE
:app:prepareComAndroidSupportTestEspressoEspressoCore22Library UP-TO-DATE
:app:prepareComAndroidSupportTestEspressoEspressoIdlingResource22Library UP-TO-DATE
:app:prepareComAndroidSupportTestEspressoEspressoIntents22Library UP-TO-DATE
:app:prepareComAndroidSupportTestExposedInstrumentationApiPublish03Library UP-TO-DATE
:app:prepareComAndroidSupportTestRules03Library UP-TO-DATE
:app:prepareComAndroidSupportTestRunner03Library UP-TO-DATE
:app:prepareComNovodaRxpresso015Library UP-TO-DATE
:app:prepareDebugAndroidTestDependencies
Conflict with dependency 'io.reactivex:rxjava'. Resolved versions for app (1.0.12) and test app (1.0.10) differ.
Error:Execution failed for task ':app:prepareDebugAndroidTestDependencies'.
> Dependency Error. See console for details

I'm used to Composer (PHP), where you have a lock file and a dependency file, in the lock file you lock your dependencies of packages (to the patch version), but you specify the range in the dependency file (so say 1.2.*), so the build is still deterministic.

For this reason I assumed that you should lock your dependencies with an exact version in your project, and libraries could simply declare the range of packages they're compatible with (assuming semantic versioning is the major version, or the minor if you need a certain feature introduced with that release).

Now it's clearer tho, I don't need a higher version in my project, just thought it was a good idea to have the wildcard in the library. :)