Adopt views-frames 2.0.0 — index type enforcement + CONFORMANCE_FLOOR 2.0.0

What changed

views-frames 2.0.0 is the package's first MAJOR. A falsification audit found that the three
frame constructors never type-checked index — they read one attribute off it, n_rows,
and a frame has one. So PredictionFrame(values, another_frame) constructed silently, and the
published assert_summarizer_contract then certified the result: a contract checker
issuing a false pass.

That now raises TypeError. Full decision and migration: ADR-028.

What you need to do

Change the constraint and re-lock. If you pass a real SpatioTemporalIndex — which is what
the type hint has always said — nothing else changes.

What actually breaks

If your code…	Before	Now
passes a `SpatioTemporalIndex` as `index`	works	works, unchanged
passes a frame or other object as `index`	silently constructed	`TypeError`
passes a non-index to `reindex`/`reindex_fill`	`AttributeError` on `_level`	`TypeError`
mutates `frame.values` in place	silently corrupted buffer-sharing frames	`ValueError: read-only`
calls `map_estimate` on `inf`/`NaN` draws	bare `IndexError`	`ValueError` naming the cause

Only row 4 can plausibly break working code, and ADR-025 already documented that operation as
unsupported. A quick check: grep -rn "\.values\[" src/ — assignments are the ones to look at,
comparisons are fine.

`CONFORMANCE_FLOOR` moves to `2.0.0`

First move since the v1.0.0 freeze. If you assert the floor anywhere, update the expected value.

You are also two releases behind on a real fix

You are pinned to 1.10.2, so you never picked up 1.11.0, which fixed a defect in the
published MAP-containment law: it was wrong on tied draws, failing ~6% of rows on
zero-inflated integer count posteriors — this platform's primary data shape. Moving to 2.0.0
picks that up too.

🤖 Filed as part of the coordinated MAJOR bump process (views-frames GOVERNANCE.md, register C-13).

Specific to this repo

pyproject.toml:20:

-views-frames = ">=1.10.2,<2"
+views-frames = ">=2.0.0,<3"

Then poetry lock (your poetry.lock currently pins 1.10.2).

This repo volunteered to adopt the C-88 MAP-containment fix first; that fix shipped in 1.11.0
and this is the release that brings it to you.

Pre-flight scan of this repo — this looks like a clean re-lock

Scanned before you start:

✅ No in-place `.values` mutation

The one row of the migration table that can break working code. Three files mention
.values[:

views_postprocessing/contract/historical.py         reads only
views_postprocessing/contract/frame_extraction.py   reads only
tests/test_hop_b_sink_e2e.py                        reads only

All reads — no assignments. Nothing to change.

✅ No `CONFORMANCE_FLOOR` assertion

Nothing here pins the floor value, so its move 1.0.0 → 2.0.0 needs no edit.
(views-faoapi does pin it and has one test to update.)

✅ You do not call `assert_summarizer_contract`

So the checker change does not reach you.

Expected work

pyproject.toml:20 → views-frames = ">=2.0.0,<3"
poetry lock
Run the suite

You also pick up 1.11.0's C-88 fix in the same move — the MAP-containment law was wrong on
tied draws, failing ~6% of rows on zero-inflated integer count posteriors. This repo
volunteered to adopt that first; this is the release that delivers it.

Scanned read-only from views-frames. Nothing in this repo was modified.

Merge pull request #291 from views-platform/chore/286-adopt-views-fra…

Blocked upstream — but the risk that mattered is settled

Every published views-pipeline-core release, through the latest 3.1.1, pins views-frames <2.0.0. Measured against PyPI metadata:

3.0.0  views-frames<2.0.0,>=1.10.2
3.0.1  views-frames<2.0.0,>=1.10.2
3.1.0  views-frames<2.0.0,>=1.10.2
3.1.1  views-frames<2.0.0,>=1.10.2

poetry lock refuses the resolution outright. So the pin here is unchanged and this issue stays open — adopting 2.0.0 needs views-pipeline-core to widen first. Two repos changing together, so raising it there is Simon's call.

What was checked meanwhile, so the wait is not wasted

The byte question is answered, and it was the one worth answering first. contract/wire/shard.py emits through views_frames.io.arrow, so a MAJOR could have changed delivered bytes — a three-repo fixture re-vendor, the shape of C-72. Measured in an isolated environment at the pinned toolchain (pyarrow 16.1.0, numpy 1.26.4):

views-frames	emitted shard sha256	equals committed §10 fixture
1.10.2 (control)	`203650fd…12c54`	yes
2.0.0	`203650fd…12c54`	yes

All 61 frames-dependent tests pass at 2.0.0 there — including the three byte-parity modules that cannot even run in a drifted local venv.

The other three breaking changes were checked against the code rather than assumed:

change	this repo
`index` must be a real `SpatioTemporalIndex`	`contract/frames.py` passes `_pgm_index(...)` — safe
`frame.values` read-only	all three `.values[...]` sites read; none assigns
`reindex` type check	not used
`CONFORMANCE_FLOOR` → 2.0.0	not asserted anywhere

So when the constraint widens this is: change the pin, re-lock, run the suite.

Recorded in tests/fixtures/wire_contract/README.md (#291), beside the existing claim that views_frames is not version-sensitive — which was written for 1.x and now has a MAJOR behind it. So nobody re-opens the byte question later.

Also noted: we are locked at pipeline-core 3.0.1 while 3.1.1 is published. Separate scope, not touched here.

views-pipeline-core 3.3.0 is on PyPI (https://github.com/views-platform/views-pipeline-core/releases/tag/3.3.0) with views-frames = ">=1.10.2,<3.0.0" (our #488, measured on 2.0.0). Your own <2 pin is now the only thing between you and 2.0.0. One caveat you'll hit if your env also holds views-reporting: views-evaluation 2.0.0's [frames] extra still caps views-frames <2 (views-evaluation#91).

Merge pull request #306 from views-platform/chore/286-adopt-views-fra…

Adopted — #306, merged to development 2026-09-19, the same day the upstream blocker lifted.

views-frames >=1.10.2,<2 → >=2.0.0,<3, re-locked. Six packages moved (views-frames 2.0.0, views-pipeline-core 3.3.0, views-evaluation 2.0.0, three transitive). pyarrow stayed at 16.1.0, which was the one thing that had to hold.

Verified in CI, which was the first execution of the new lock — no interpreter on the developer machine can install it (C-104). The 3.11 job installed exactly views-frames 2.0.0 / pipeline-core 3.3.0 / pyarrow 16.1.0 and reported 509 passed, 0 failed. The ADR-013 §10 byte-parity fixtures are not gated, so they ran and passed under the MAJOR — the 2026-08-21 measurement predicted that, and CI confirmed it.

The views-evaluation [frames] extra caveat did not apply: pipeline-core 3.3.0 requests views-evaluation without it, and this repo depends on neither views-evaluation nor views-reporting directly.

Reaches PyPI at the next release; 1.2.0 is unchanged.

Navigation Menu

Repository navigation

Adopt views-frames 2.0.0 — index type enforcement + CONFORMANCE_FLOOR 2.0.0 #286

What changed

What you need to do

What actually breaks

`CONFORMANCE_FLOOR` moves to `2.0.0`

You are also two releases behind on a real fix

Specific to this repo

Pre-flight scan of this repo — this looks like a clean re-lock

✅ No in-place `.values` mutation

✅ No `CONFORMANCE_FLOOR` assertion

✅ You do not call `assert_summarizer_contract`

Expected work

Blocked upstream — but the risk that mattered is settled

What was checked meanwhile, so the wait is not wasted

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Adopt views-frames 2.0.0 — index type enforcement + CONFORMANCE_FLOOR 2.0.0 #286

Description

What changed

What you need to do

What actually breaks

CONFORMANCE_FLOOR moves to 2.0.0

You are also two releases behind on a real fix

Specific to this repo

Activity

Polichinel commented on Aug 18, 2026

Pre-flight scan of this repo — this looks like a clean re-lock

✅ No in-place .values mutation

✅ No CONFORMANCE_FLOOR assertion

✅ You do not call assert_summarizer_contract

Expected work

Polichinel commented on Aug 21, 2026

Blocked upstream — but the risk that mattered is settled

What was checked meanwhile, so the wait is not wasted

Polichinel commented on Sep 19, 2026

Polichinel commented on Sep 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`CONFORMANCE_FLOOR` moves to `2.0.0`

✅ No in-place `.values` mutation

✅ No `CONFORMANCE_FLOOR` assertion

✅ You do not call `assert_summarizer_contract`