Re: [Jython-dev] Versions in extlibs and Gradle

[Adam B. <ada...@gm...>]

Good topic. It’s really really good to see Jython moving to declared dependency management instead of a jar folder. 2 cents from me ...

At work I have always favoured strictly pinned versions, for determinism / repeatability reasons. Being able to reproduce exactly the classes being used at a particular point in time can be invaluable with deep dependency trees and wide usage of different versions.

People usually aren’t too shy about forcing different dependency versions if needed in my experience.

I do see some advantages to the less strict versions, around maintenance and advertising to developers the choice of specific version is somewhat arbitrary (which it often is, especially when talking about patch versions.)

This blog post has a good discussion about pinned versions
https://brock.io/post/repeatable_android_builds/

It also points on to an interesting dependency lock plugin.
https://github.com/nebula-plugins/gradle-dependency-lock-plugin

I haven’t used that plugin in anger, but it might allow the best of both worlds.

Cheers 
Adam

> 在 2018年8月14日，上午5:36，Jeff Allen <ja...@fa...> 写道：
> 
> 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
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev