skip to content

Explain the priority relationship between `require`, `prefer`, and `strictly`, and how they combine within a single version block.

level: seniorimportance: should knowfreq 35%

answer

  1. strictly/require = acceptable set
  2. prefer = selection bias, lowest priority
  3. reject subtracts from the set
  4. prefer never overrides a hard bound
  5. in-range transitive request can beat prefer

basics

~20 s

strictly is the hard boundary (nothing outside it is allowed), require is the acceptable range within that, and prefer is a low-priority hint used only when the range still leaves a choice. Priority: strictly defines the box, require narrows, prefer picks inside.

solid answer

~40 s

Within one `version { }` block these compose rather than compete. **`strictly`** sets the absolute boundary: any version outside it is unacceptable and conflicts fail the build. **`require`** declares the acceptable range (a floor/range) and is upgradeable by resolution *as long as it stays inside any strict bound*. **`prefer`** is the lowest-priority signal — a tie-breaker applied only when the allowed set still leaves freedom and nothing else forces a specific version. So a common combo is `strictly("[1.0,2.0["); prefer("1.5")` meaning "must be some 1.x, and among those pick 1.5 unless another participant needs something else in-range". You can also combine `require` + `reject`. The mental model: `strictly`/`require` define *which versions are legal*; `prefer` only influences *which legal version is chosen* when there's still a choice — it never widens or overrides the legal set.

code

kotlin · 6 lines
kotlin
implementation("io.netty:netty-all") {
    version {
        strictly("[4.1.90, 4.2[") // compatibility window
        prefer("4.1.100.Final")   // default within window
    }
}

go deeper

for a junior

Know the three keywords and that prefer is just a hint.

for a middle

Explain that strictly/require define what's legal and prefer only chooses among legal versions with lowest priority.

for a senior

Articulate the acceptable-set vs selection split and how combos (strictly+prefer+reject) interact with transitive requests.

for a principal

Reason about authoring precise, publishable version policies in platforms and the downstream effects of strict windows plus prefer defaults.

## Two questions, two roles Resolution answers two things: (1) *which versions are acceptable* and (2) *which acceptable version to pick*. Rich-version keywords map onto these: - **`strictly`** and **`require`** define the **acceptable set**. `strictly` is a hard wall (conflicts → failure). `require` is a softer floor/range that can be upgraded by higher requests but only *within* any strict wall. - **`prefer`** influences only the **selection** among acceptable versions, with the **lowest** priority. It's a hint used when nothing stronger pins the choice. - **`reject`/`rejectAll()`** subtract from the acceptable set. ## How they combine ```kotlin implementation("org.example:lib") { version { strictly("[1.0, 2.0[") // legal set: any 1.x prefer("1.5") // among legal versions, lean to 1.5 reject("1.4") // but never 1.4 } } ``` Here the legal set is `1.x minus 1.4`; `prefer("1.5")` biases selection to 1.5 *if the rest of the graph doesn't force another in-range version*. If a transitive edge needs `1.8` (in range), Gradle may pick 1.8 — `prefer` yields because something concrete wants 1.8. But it can never pick `2.x` (outside strict) or `1.4` (rejected). ## prefer vs require priority If you write `require("1.5")` and `prefer("1.6")` with `1.6` available and in range, `prefer` can raise the choice to 1.6 — `prefer` is a *bias toward a specific version* within the acceptable set, not a constraint. But `require` always outranks `prefer` when they conflict on acceptability: `prefer` can never select a version that `require`/`strictly`/`reject` forbid. ## Why this matters Understanding the layering lets you write precise declarations: use `strictly` for hard compatibility windows, `require` for minimums, `prefer` for a default within the window, and `reject` to carve out bad releases — all in one coherent block that publishes to Gradle Module Metadata.

  • If strictly allows 1.0–1.9 and a transitive edge requires 1.8 while you prefer 1.5, what resolves?
    1.8 — it's inside the strict window and a concrete requirement, so it outranks the prefer hint.
  • Can prefer ever cause the build to fail?
    No. prefer is only a tie-breaker within the acceptable set; if its target isn't acceptable it's simply ignored, never a failure.

Booking a flight: strictly = the only dates you can travel (hard), require = preferred earliest date, prefer = 'morning if possible' — the time-of-day wish never overrides which dates are even bookable.

saying these in an interview costs you the question

  • Saying prefer overrides strictly or require
  • Claiming require pins exactly like strictly
  • Believing prefer is honored even against a concrete in-range transitive request

context

resolving links…