This message was deleted.

First, let's review the documentation:

The strings

rc

,

snapshot

,

final

,

ga

,

release

and

sp

are considered higher than any other string part (sorted in this order):

1.0-zeta

<

1.0-rc

<

1.0-snapshot

<

1.0-final

<

1.0-ga

<

1.0-release

<

1.0-sp

<

1.0

.

Interesting. I would have expected release to be taken. Maybe we are both wrong, or you found a bug.

Oh, here it is:

prefer

This is a very soft version declaration. It applies only if there is no stronger non dynamic opinion on a version for the module. This term does not support dynamic versions.

Definition can complement

strictly

or

require

.

When defined, this overrides any previous

prefer

declaration and clears previous

reject

.

I think it just means within one rich version. If you for example have

version {
    reject("1")
    reject("2")
    prefer("3")
    prefer("4")
    reject("5")
    reject("6")
}

Then the

prefer("4")

will override the

prefer("3")

and for whatever reason clear the rejects for 1 and 2. So you end up with prefer 4 and reject 5 and 6.

In other words, you think the "replacement" behavior is scoped to a single

Dependency

instance, not to an entire

Configuration

Exactly, everything else also would not make any sense.

This looks buggy to me. It looks to me that we're comparing the preferred versions lexicographically and picking the "highest" version. If you had

1.0-zzz

, you'd get that version instead. Oddly, if you use a dynamic version anywhere in the graph (

:brazil:FooLib:+

), you get the

1.0-release

version instead. If instead of using a rich version, you use those same versions with the simple GAV notation, you also get

1.0-release

, so I suspect there's a bug when there are no stronger constraints and we have to choose between the preferred versions.

Oddly, if you use a dynamic version anywhere in the graph (

:brazil:FooLib:+

), you get the

1.0-release

version instead.

That makes sense, since that resolves to the equivalent of

require("1.0-release")

, right? And

1.0-release

is ranked higher than almost any other qualifier. It's subject to those special rules

ah, yeah, I guess it's looking at all the available versions and resolving to the latest via a different path. I thought that was somehow influencing the comparisons between preferred versions

It also looked to me like it was applying ASCIIbetical sorting rules and not the full Gradle version ordering rules with special cased qualifiers etc

I found something that looks promising. I'm going to get another set of eyes and run it through CI before I spend more time on it