Found while pinning METPO in a downstream consumer (kg-microbe) and trying to work out what to point at.
What the releases look like
| release |
assets |
| 2026-06-12 (Latest) |
0 |
| 2026-06-02 |
0 |
| 2026-05-19 |
9 — metpo.owl/obo/json, metpo-base.*, metpo-full.* |
| 2026-03-24 |
0 |
| 2025-12-12 |
0 |
2026-06-12 is a normal published release, not a draft or prerelease, with proper auto-generated notes. It just has nothing attached. So the current Latest release offers a consumer no artifact.
There is no release/publish workflow among the ten on main (actionlint, artifact-freshness, codeql, curie-prefix-case, metpo-content-lint, python-quality, qc, secret-scan, sparql-metatest, zizmor), so attaching assets appears to be a manual step, done once in May and not since.
Why this is a consumer problem rather than a cosmetic one
Raw tag paths do work — https://raw.githubusercontent.com/berkeleybop/metpo/refs/tags/2026-06-12/metpo.owl returns 200 — so nothing is unreachable. The problem is that there are now two ways to pin a version and they disagree about whether a given release exists at all. A downstream that pinned 2026-05-19 by release asset and tries to move to 2026-06-12 finds nothing there and has to discover the raw-tag form independently.
Given artifact-freshness.yml and #433 ("switch SoT to repo OWL"), I suspect the intended answer is repo artifact at a tag, releases are just notes. If so this is a documentation gap rather than a regression, and the fix is a line in the README saying so. If instead the May release was the intended pattern, the last two releases are missing a step.
Either way, worth stating explicitly somewhere a consumer will look:
- which file is canonical (
metpo.owl vs metpo-full.owl vs metpo-base.owl);
- whether to pin a tag path or a release asset;
- whether
main is expected to be consumable directly (kg-microbe currently pulls refs/heads/main/metpo.owl, which is unpinned and will drift — our problem to fix, but the absence of a stated alternative is why it was set up that way).
Related: #433, #499 (closed, artifact-drift guardrail), #148.
Found while pinning METPO in a downstream consumer (kg-microbe) and trying to work out what to point at.
What the releases look like
metpo.owl/obo/json,metpo-base.*,metpo-full.*2026-06-12is a normal published release, not a draft or prerelease, with proper auto-generated notes. It just has nothing attached. So the current Latest release offers a consumer no artifact.There is no release/publish workflow among the ten on
main(actionlint,artifact-freshness,codeql,curie-prefix-case,metpo-content-lint,python-quality,qc,secret-scan,sparql-metatest,zizmor), so attaching assets appears to be a manual step, done once in May and not since.Why this is a consumer problem rather than a cosmetic one
Raw tag paths do work —
https://raw.githubusercontent.com/berkeleybop/metpo/refs/tags/2026-06-12/metpo.owlreturns 200 — so nothing is unreachable. The problem is that there are now two ways to pin a version and they disagree about whether a given release exists at all. A downstream that pinned2026-05-19by release asset and tries to move to2026-06-12finds nothing there and has to discover the raw-tag form independently.Given
artifact-freshness.ymland #433 ("switch SoT to repo OWL"), I suspect the intended answer is repo artifact at a tag, releases are just notes. If so this is a documentation gap rather than a regression, and the fix is a line in the README saying so. If instead the May release was the intended pattern, the last two releases are missing a step.Either way, worth stating explicitly somewhere a consumer will look:
metpo.owlvsmetpo-full.owlvsmetpo-base.owl);mainis expected to be consumable directly (kg-microbe currently pullsrefs/heads/main/metpo.owl, which is unpinned and will drift — our problem to fix, but the absence of a stated alternative is why it was set up that way).Related: #433, #499 (closed, artifact-drift guardrail), #148.