Repository navigation
ADR-013 §2.2: lift the pipeline_core_version caveat — 3.0.0 shipped, but 'unknown' now covers every dev install #228
Description
What changed
ADR-013 §2.2 pins the provenance sub-schema every wire artifact carries, including pipeline_core_version. As adopted (2026-07-15) that field was declared unreliable: no real pipeline-core releases existed, so the contract instructs consumers not to treat it as authoritative until the release train cut one.
views-pipeline-core 3.0.0 shipped to PyPI on 2026-08-03. The condition the caveat depended on is met.
The ask
Amend ADR-013 §2.2 in place with a dated lift note, per that ADR's errata convention. The accurate statement is narrower than "it is now reliable" — see below.
What the field now means, precisely
pipeline-core#403 corrected a defect found while lifting this on our side, and it changes the wording you want:
| Producer | pipeline_core_version |
|---|---|
| installed from PyPI (a released wheel) | authoritative — the metadata was written by the release that built the wheel, so it cannot disagree with the code beside it |
editable install (pip install -e, i.e. any developer machine) |
"unknown" |
| no distribution installed | "unknown" |
Why the middle row exists. An editable install's .dist-info records the version that was current when pip install -e last ran and never tracks the source afterwards. Measured in pipeline-core's own environment on 2026-08-04: metadata said 2.3.0 while pyproject.toml said 3.0.0 — a full major version stale, and it was being stamped into published artifacts with nothing saying so.
That is now returned as "unknown" rather than as a stale number. It is not a loss of information: 2.3.0 carried none, it only looked like it did.
Suggested wording for the lift note
Lifted 2026-08-0X.
pipeline_core_versionis authoritative when the producing pipeline-core was installed as a released distribution (3.0.0, PyPI, 2026-08-03). It is"unknown"when produced from an editable/development install, which is deliberate — an editable install's recorded version does not track its source. Consumers must continue to treat"unknown"as "do not infer the producing version", and must not treat it as an error.
The last clause matters: "unknown" is now a wider set than before, because it includes every developer run. A consumer that starts rejecting "unknown" on the strength of this lift would break local workflows.
Downstream
views-faoapi is the other reader of this field and inherits both halves. Worth a note to them once §2.2 is amended.
Cross-ref: views-pipeline-core#279 (closed), #403, its register C-280.
Activity
Polichinel commentedon Aug 10, 2026
Done — Erratum E3, merged as PR #237.
Lifted, with one correction to the suggested wording. The two halves are not equally in force:
"unknown"from an editable install — not in any released version. pipeline-core#403 merged 2026-08-04 13:58; 3.0.0 was uploaded 2026-08-03 02:06, a day and a half earlier. It becomes true of producers at pipeline-core's next release.Your note reads as though both are live, which is why E3 splits them.
Verified here rather than assumed: this repo's environment reports
importlib.metadata2.3.0 against source that is 3.0.0, and_pipeline_core_version()returns"unknown"with the fix present — so the defect and the fix both reproduce.Your operational point is carried verbatim: consumers treat
"unknown"as do not infer, never as an error, and the set producing it widens at the next release.E3's unreleased claim expires, so it carries a check —
test_e3s_claim_about_unreleased_behaviour_is_still_truefails if the installed pipeline-core is a released distribution past 3.0.0. Live in CI (which installs from PyPI), inert in an editable environment. Mutation-proven.Nothing in this repo changes: Hop-B re-embeds the Hop-A header untouched, so we forward the value and never compose it.
contract_versionstays 1.5.Not done here, per your last section: the note to views-faoapi as the other reader.