Merge main into development; test the declared R 4.2 floor

[achubaty]

development never received the reusable-workflow migration — it landed on main only, so the branch every PR targets still ran the old self-managed workflows, including install-spatial-deps@v0.1.

1. Merge main → development

One conflict, in .github/workflows/R-CMD-check.yaml: development's copy still triggered on master, a branch this repo no longer has. Resolved in favour of main's thin caller.

The merge also removes the last stale spatial pins from development — main's versions of pkgdown.yaml, test-coverage.yaml and update-citation-cff.yaml had already dropped install-spatial-deps. After this merge there are none left on the branch:

$ grep -rn "install-spatial-deps@" .github/workflows/
  (none)

That matters, because every published tag — v0.1 through v0.5 — still runs add-apt-repository -y ppa:ubuntugis/ubuntugis-unstable, which installs libgdal37 while Posit's noble binaries link libgdal34. Only @main dropped it.

2. Test the R 4.2 floor

DESCRIPTION declares R (>= 4.2). The base matrix stops at oldrel-1 — currently R 4.5 — leaving three unrestricted minor versions untested.

oldrel-N cannot close that gap, because the ladder is platform-dependent and not monotone. Resolved against the exact platform string setup-r sends:

ubuntu-latest (noble)      ubuntu-22.04
oldrel-1 -> 4.5.3          oldrel-1 -> 4.5.3
oldrel-2 -> 4.4.3          oldrel-2 -> 4.3.3   skips 4.4
oldrel-3 -> 4.3.3          oldrel-3 -> 4.2.3
oldrel-4 -> 4.1.3   !!     oldrel-4 -> 3.6.3   !!
oldrel-5 -> 4.1.3   dup    oldrel-5 -> 4.1.3

On ubuntu-latest, R 4.2 is unreachable by any oldrel index. Exact versions resolve identically on Linux, macOS and Windows (4.2 → 4.2.3), and Posit ships noble .debs down to 4.0.5.

Adds ubuntu legs at 4.4, 4.3 and 4.2.

If a leg fails

That is the finding, not a reason to drop the leg — it would mean the declared floor was never true. Either fix the package or raise Depends:.

Note

SpaDES has no direct spatial dependency of its own, so once system-deps is exposed as a workflow input it should set system-deps: false and stop paying for a GDAL install it never uses.

🤖 Generated with Claude Code

[achubaty]

Correction: the oldrel-N table in the description is wrong

I need to correct the evidence I gave. The mapping table above does not reproduce. Re-tested across ~4,500 requests — sequential, concurrent, cold-key — every platform currently returns the clean sequence:

linux-ubuntu-24.04:  oldrel/1..7 -> 4.5.3, 4.4.3, 4.3.3, 4.2.3, 4.1.3, 4.0.5, 3.6.3
linux-ubuntu-22.04:  identical
mac / win:           identical

So oldrel-4 does resolve to 4.2.3 on noble today, and my claim that "R 4.2 is unreachable by any oldrel index" was not the steady state. Sorry — I reported a snapshot as if it were the behaviour.

What is actually wrong, and why this PR still stands

The readings I saw were real, but they were stale cache responses, and the underlying bug is worse than a bad mapping.

The resolver behind setup-r is r-hub/rversions.app. In lib/cache.js, MAX_AGE is 3600s, the key + "/old" entry never expires, and stale() returns that never-expiring value while refreshing in the background — so the corrected value only appears on the next request. In lib/endpoints.js the hourly refresh list covers r-oldrel/1..10 but contains zero resolve entries.

Consequence: any /resolve/oldrel/N/<os> tuple not requested within the last hour serves an arbitrarily old answer on its first request, then self-heals. That is why the plain /r-oldrel/N endpoint is always clean while /resolve/... drifts, why rarely-used platform tuples drift most, and why my readings vanished on retry. It was caught live three times during verification, including a self-inconsistent response labelled oldrel/4 while returning 4.1.3.

The failure is silent. A stale answer carries a valid installer URL, so CI installs a different R than the one requested and the job passes. A version-sensitive failure then cannot be reproduced.

Why exact pins are still the right fix

Not because the ladder is misnumbered — it usually isn't — but because an exact pin on a closed R branch is time-invariant. 4.3 resolves to 4.3.3 whether the cache entry is fresh or six months old, so staleness cannot silently substitute a different R. (Worth knowing: pinning a current branch such as 4.6 is not immune, since that branch still moves. Only closed branches, or full versions like 4.3.3, are fully safe.)

The second motive is unchanged and independent of any of this: the base matrix stops at oldrel-1 — currently R 4.5 — which is above this package's declared floor, so the floor was never tested regardless of how the ladder resolves.

One trade-off this creates

Exact pins do not track upward the way oldrel-N does. When R 4.7 ships, the default legs move to 4.7/4.6 while these stay put, and a gap opens with nothing to announce it. That is a deliberate trade — silence about a gap is preferable to silently testing the wrong R — but it does make these legs an annual review item.

An upstream bug report for the cache staleness has been drafted and not yet filed.