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

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

That's a pretty neat idea too, and I can see how it would work.

Adam

On Mon, 10 Sep 2018 at 23:16, Eero Aaltonen <eer...@ik...> wrote:

> 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 <eer...@ik...>
> 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 <ada...@gm...>
>> 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 <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
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>