PDE update checks silently fail because `/download/latest.txt` returns `1.5.1` instead of a revision number

[SableRaf]

Tl;dr: Looks like Processing users may not have been getting update notifications in the PDE since October last year.

Normally, Processing shows a popup when a newer version is available.

The way the PDE knows a new version is available is by reading https://processing.org/download/latest.txt and comparing the revision number with its own.

Right now the number is both wrong (1.5.1 when the latest stable version is 4.5.6) and the wrong format (the PDE expects a revision number like 1434 and NOT semantic versioning like 4.5.6).

You can also come discuss this on this Discord thread for quicker back and forth and unformed thoughts. However, please post any relevant insights in the comments below so the findings are not siloed to Discord.

Warning

AI Disclosure: The report below was generated with AI help. Specifically, Claude Opus 5 for the initial report, with verification by Codex Astra GPT 6 High

I have verified that the report is directionally sound but human replication/investigation is necessary. I added some notes in the body of the issue for additional context or where I disagreed with the machine.

Summary

https://processing.org/download/latest.txt currently returns:

1.5.1

It should return the integer build number of the latest stable release, currently 1434 for Processing 4.5.6.

Impact

The PDE update checker reads this endpoint:

• UpdateCheck.java:62 defaults LATEST_URL to https://processing.org/download/latest.txt.
• app/build.gradle.kts:66 configures the same URL.

readInt calls Integer.parseInt(reader.readLine().trim()). The response 1.5.1 throws NumberFormatException, stopping the check before it compares the latest build with the installed revision.

The background thread catches and ignores the exception. Clients using this endpoint therefore receive no PDE update prompt while it serves this value.

Processing 3 uses the same path over HTTP; its current behavior also depends on HTTP serving and redirects.

Note

Raph: This could have been a contributing factor to the decline in downloads we have observed beginning in October 2025 (speculative).

Regression

The source regression was introduced by “Automate selection of latest Processing releases” (bd09d71a, October 15, 2025), then merged on October 16 (4bc0ef7b). The exact production onset requires deployment records.

That change replaced the manually ordered selection with a generated list. Its first entry changed from processing-1310-4.4.10 to processing-1.5.1, without changing the build hook that assumes the first entry is the latest release.

Executing the existing build hook with historical selection data confirms:

Selection data	Generated latest.txt
Before the regression commit	1310
At the regression commit	1.5.1
Current checkout	1.5.1

Cause

onPostBuild in gatsby-node.js writes:

const latest = releases.selectedReleases[0];
const [name, number, version] = latest.split('-');
fs.writeFileSync(path.join(__dirname, 'public', 'download', 'latest.txt'), number);

Two assumptions fail:

1. fetchReleases.js groups releases under numeric major-version keys and uses Object.values(), which enumerates those keys in ascending order.
2. The tag processing-1.5.1 has no build-number segment, so splitting it writes the version string as the build number.

The current selection is:

"selectedReleases": [
  "processing-1.5.1",
  "processing-0225-2.1.2",
  "processing-0270-3.5.4",
  "processing-1434-4.5.6"
]

Even selecting an older tag with a valid numeric build would incorrectly suppress update prompts for newer installed versions.

Suggested fix

Note

Raph: The suggested fix below continues to use selected.json as the source of truth. I don't think that's the right call. We could get the revision number directly from the release tag on GitHub.

Select the highest build number independently of array order, skip tags without a build-number segment, and fail the build if no valid candidate exists:

exports.onPostBuild = () => {
  const { selectedReleases } = require('./content/download/selected.json');
  const build = selectedReleases
    .map((tag) => tag.match(/^processing-(\d+)-/))
    .filter(Boolean)
    .map((match) => Number(match[1]))
    .sort((a, b) => b - a)[0];

  if (!build) {
    throw new Error(
      'latest.txt: no release with a build number in selected.json'
    );
  }

  fs.writeFileSync(
    path.join(__dirname, 'public', 'download', 'latest.txt'),
    String(build)
  );
};

This produces 1434 for the current selection, including with the array reversed, and throws when no build-number tags exist.

Two additional validation gaps remain:

• The release generator does not exclude prereleases from selectedReleases. Stable-release eligibility should be checked explicitly.
• This numeric extraction still accepts malformed build numbers. For example, the earlier typo introducing processing-13010-4.4.10 (adb2c6ea), corrected five minutes later (cbe4958e), would pass this check. Validation against release metadata would provide stronger protection.

The hook runs during builds, not local development. After deploying the fix, eligible clients on older builds should resume receiving update prompts.