Versions in extlibs and Gradle

One of the things we were looking forward to with Gradle was that it 
would become easier to control the versions of JARs (modules) we depend 
on. Gradle can get quite sophisticated about this: you can have anything 
you want. Only ... what do we want?

  * If we only specify a module name, we'll get the latest all the time
    (with obvious risks).
  * If a module moves to a new API we aren't ready for, we can specify
    the version in part (3.1.+), and continue to take minor/patch releases.
  * If a module has to be pinned to an exact version, we can name it
    explicitly (or an acceptable range).

At least we don't have to check the JAR in: just change the dependency 
statements (once we use Gradle exclusively). If we build distributions 
with Gradle like the JARs we build now, I believe we end up jarjar'ring 
the dynamically downloaded modules, but I haven't tried that yet.

A second dimension is when other projects cite Jython as a dependency 
and get our dependencies transitively. Consuming projects are able to 
override our version choices (if I understand correctly, 
https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:enforcing_dependency_version). 
The less specific we are about version,  the more helpful to consumers. 
However, these might be untested combinations.

Any thoughts how to tell, for a given module, what the sensible policy 
would be?

-- 
Jeff Allen


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev