This is cool - two things come to mind:

• we should have a policy of dropping packages that are holding on updates for too long. E.g. picture the scenario where a package that has many dependants is blocked by a package that has not many users - the former should not be held up. Maybe we can have some sort of expiration (e.g. holding a package for 30 days triggers removal or something like that)
• we could wire this up to @pacchettibotti automatically opening issues in the repos that need updating to the newer version, to speed up the process of the package sets catching up to things

Yeah, I agree. I don't have a specific policy in mind but directionally I'm on board. To what degree should that be encoded into this script's report? We could augment this with more data than it currently gives.

Also, we could extend this with a planner that makes it more obvious whether the discovered versions will even work together and suggest a batch. Something like:

1. Give every candidate package two choices: its current version or reported candidate.
2. Check every package manifest against the exact proposed package-set versions.
3. Maximize the number of accepted candidates while satisfying all declared ranges.
4. Repeat until stable, since rejecting one candidate can invalidate another; like for example, rejecting Elmish 0.14 also requires rejecting elmish-html@0.12.0.
5. Run one read-only atomic compilation of the selected plan to prove it

For this batch, this would have discovered the 14 packages that work without me having to do a separate manual triage:

• morello excludes Barlow 1.0.
• elmish-hooks excludes Elmish 0.14, which consequently excludes the new elmish-html.
• bolson and deku exclude Hyrule 2.4.
• dotenv and node-execa exclude node-child-process 12.

...this doesn't help with what you're describing, but maybe we can re-think this script such that it's a more useful swiss-army-knife for helping get the package sets updated with the best options when it can't be done automatically due to breaking changes.

To what degree should that be encoded into this script's report?

I to get us a good glance we could have:

• who is holding up who
• and for how long; that is: how many days ago the incompatible version was published
• how many dependants each of the packages involved have

Also I think we could be running this in a weekly cronjob thing in the Registry repo, opening an issue/PR if it finds something

d283822 has some followups that address your points:

1. The version check now produces JSON and markdown reports, which themselves cover staleness, direct and transitive dependant counts, blocked version ranges, reverse blockers, compiler compatibility, etc.
2. It also includes a planner which uses our bounded ranges; it considers current and compatible newer releases, maximizes upgrade count and then freshness, and supports coordinated upgrades
3. You can optionally compile the planned payload with --verify so that you know the proposed plan will work
4. Adds a weekly workflow which writes to a rolling issue with that week's report (doesn't actually submit anything)

Tried it out with a live run against package set 78.1.0 / compiler 0.15.15 and it produced a workable plan — including settling on hyrule@2.3.9 as an ugrade since 2.4.0 is blocked.

Latest commit is a prototype, still hacking on it a little. But as I was working on the version check script, I realized we could be doing a lot more automatically — and still safely — to update the package sets. Our current automatic upgrade is basically just "try all new packages in the last 24hrs, and if any fail, go sequentially and only include ones which succeed." Very naive, and if a package doesn't work in its 24h window for whatever reason it is never retried — even if it would work later on (such as a dependency finally upgrading).

So the new prototype implements one shared planner that can be used by both the package set updater and the version check workflow. Any version of a package that's already in the set which is newer than what's in the set is eligible for any new plan, plus recently uploaded packages even if they've never been in the set. We restrict to a single compiler version but otherwise ignore ranges. We still try all packages first, but then we do bounded best-first latest/intermediate/current searches.

The package set updater, if it is capable of finding a nonempty addition/upgrade plan, can just submit it. If it finds removals, downgrades, etc. then we can have that notify trustees for action, but it will never be automatically done.

Greptile Summary

This PR adds a PackageSetVersionChecker script and GitHub Actions workflow that compile-verifies all pending registry upgrades against the latest package set and reports both automatically-applicable updates and manually-reviewable removals. It also refactors the package-set API to be strictly atomic (removing the previous sequential/partial-success path), extracts the compile-guided planner logic into its own PackageSetPlanner module, and updates the spec to reflect the new guarantees.

• New PackageSetVersionChecker script: reads all registry metadata/manifests, re-uses the plannerCandidates traversal from the updater, plans upgrades with planUpgrades + analyzeRemovals, and renders a Markdown report with compile-verified payloads ready for trustee submission.
• PackageSetPlanner extraction: the planner logic (phases 1–5, removal analysis, interaction components) is now a standalone app/ module shared by both the updater and the new checker.
• API now enforces atomic package-set updates: upgradeSequential is removed; the server only accepts and publishes an exact, pre-planned payload in one shot.

Confidence Score: 5/5

The PR is safe to merge. The new checker runs entirely read-only, the planner extraction is well-tested, and the API switch to atomic-only semantics is a deliberate, clearly-reasoned design choice with matching spec updates.

The core logic reuses heavily-tested planner infrastructure, the report rendering has no mutable side-effects, the workflow correctly guards issue creation with hashFiles, and the atomic API change aligns the server behavior with the offline planning model described throughout the PR.

Files Needing Attention: .github/workflows/package-set-version-check.yml — consider whether a periodic schedule trigger should be added alongside workflow_dispatch.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[workflow_dispatch] --> B[nix run package-set-version-checker]
    B --> C{Latest package set?}
    C -- No --> D[Log warning, exit 0, no file written]
    C -- Yes --> E[Read all metadata + manifests]
    E --> F[plannerCandidates with empty additionSeeds]
    F --> G[planUpgrades: phases 1-5\nprobe budget 60]
    G --> H[analyzeRemovals\ntotal budget 100]
    H --> I[renderReport: Markdown]
    I --> J[Write version-check.md]
    J --> K[Upload artifact]
    K --> L{hashFiles != empty?}
    L -- No --> M[Skip issue creation]
    L -- Yes --> N[gh issue create]

    subgraph PackageSetPlanner
        G
        H
    end

    subgraph PackageSetVersionChecker
        E
        F
        I
        J
    end

Reviews (6): Last reviewed commit: "Automate compile-guided package set upda..." | Re-trigger Greptile