Skip to content

ADR-013 §2.2: lift the pipeline_core_version caveat — 3.0.0 shipped, but 'unknown' now covers every dev install #228

Description

@Polichinel

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_version is 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions