Re: Versions in extlibs and Gradle

Relatedly someone has apparently already implemented the "report me any new
library versions" part
https://github.com/ben-manes/gradle-versions-plugin

--
Eero

On Mon, Sep 10, 2018 at 3:50 PM Eero Aaltonen <[email protected]> wrote:

> Hope I'm not late to the party.
>
> Personally I would prefer to have the defaults the other way around,
> namely:
> - default to fixed versions
> - grab the latest versions, if requested.
>
> Although Gradle has the concept of variants, I did not find variant
> support Java libraries. Instead, I wrote my own using an environment
> variable in
> https://github.com/eaaltonen/gradle-dependency-proposal
>
> The idea is that you could test against the latest versions of libraries
> very easily just by specifying `DEPS=latest` before the build.
>
> --
> Eero
>
> On Tue, Aug 21, 2018 at 4:29 AM Adam Burke <[email protected]>
> wrote:
>
>> 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 <[email protected]> 写道：
>>
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>

_______________________________________________
Jython-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jython-dev