# `toolchain.version_newer`

Project is on a later Jadpo line.

Area 1, [Project layout and modules](../topics/project-layout-and-modules.md); not declinable; the next step is usually the human's.

`app.jadpo` names the Jadpo release line the project is written for. The
installed `jadpo` runs that line's release for you
([Which jadpo runs](../topics/which-jadpo-runs.md)); a `jadpo`
on an earlier line that can't, because it was told to run everything
itself (`JADPO_TOOLCHAIN=local`) or couldn't fetch the release, refuses the
project with this error alone, rather than misread what a later version
added:

```jadpo
application {
    jadpo: "99.0"
}
```

```text
error: This project needs Jadpo 99.0
 --> app.jadpo:2:12
  |
2 |     jadpo: "99.0"
  |            ^^^^^^ later than this jadpo
  reason: `jadpo:` names the release line the project is written for, 99.0, which is later than this jadpo's (`jadpo --version` shows it), so it stops here rather than misread what a later version added.
  next: Run it with Jadpo 99.0, which the installed `jadpo` fetches unless `JADPO_TOOLCHAIN` is `local` (human)
  rule: toolchain.version_newer
  help: https://jadpo.dev/docs/errors/toolchain.version_newer

check failed: 1 error, 1 file
```

When the installed `jadpo` couldn't fetch the release, its reason starts
with why, and its next step fits: run again once github.com can be
reached; name a published line; set `XDG_CACHE_HOME` when there is no
cache folder; or, for a download that failed its SHA-256 or attestation
check, run again to fetch it afresh, then install the newest `jadpo`,
whose trusted root may be newer, if it fails the same way. When GitHub's
API refuses for its hourly limit, it says so and to run again in an hour.
