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

[Eero A. <eer...@ik...>]

Note that this was a quick and dirty proof of concept. If you are in favor
of adopting this, we would probably want to limit the 'newest version' to
'newest version with matching major version number'. As all libraries
seemed to have semantic-ish version numbers, that should be easy.

--
Eero

On Tue, Sep 11, 2018 at 9:14 AM Adam Burke <ada...@gm...> wrote:

> 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
>>>>
>>>