Skip to content

fix(rules): stamp since with the release a rule ships in - #182

Merged
simontaurus merged 1 commit into
mainfrom
fix/since-stamp-and-validator-pin
Sep 21, 2026
Merged

simontaurus merged 1 commit into
mainfrom
fix/since-stamp-and-validator-pin

Conversation

@simontaurus

Copy link
Copy Markdown
Contributor

Two findings from a review of v1.0.0-rc.3..main. Both matter before rc.4 is tagged; the first is irreversible once it is.

Every since was one release early

extract_rules.py stamped a newly minted rule with git describe - the most recent tag. That names the previous release, not the one being cut, so a rule authored between rc.3 and rc.4 was recorded as having shipped in rc.3.

Checked against the tagged catalogues themselves:

Stamp Rules Present in that tag?
1.0.0-rc.1 66 rc.1 carried no catalogue at all
1.0.0-rc.2 7 none of the 7
1.0.0-rc.3 15 none of the 15

recorded_since() then carries each value forward forever, so tagging rc.4 would have frozen the 15 permanently.

A new rule now records since: unreleased, and scripts/promote_since.py resolves it at tag time:

$ uv run scripts/promote_since.py 1.0.0-rc.4
promoted 15 rule(s) to since=1.0.0-rc.4

It touches only unreleased entries; every other value records a release that has shipped. The existing data is shifted one release forward to what the tags prove.

spec_version() stays, but only for the catalogue header, where "the release this tree descends from" is what is meant.

The pinned validator predated its own rules

OOLD_VERSION was 0.18.1, whose oold.validation.frame has no reference_properties and never emits @embed: @never:

$ uv run --with "oold[validation]==0.18.1" python -c "from oold.validation import frame; print('reference_properties' in dir(frame))"
False

.github/workflows/main.yml runs make validate, so CI gated rc.4 with a validator older than OOLD-EXT-68fa, the MUST this range strengthened. Bumped to 1.0.1; make validate passes identically (380 ok, 76 ok, 0 failed).

Note 1.0.1 still predates the @reverse signal (OO-LD/oold-python#164, merged but unreleased), so the pin wants bumping again once that ships.

Also

docs/contributing.md gains a release section covering both: how unreleased is resolved, and when to bump the pin.

Verified: make check end to end - 380 ok and 76 ok 0 failed, spec and baseline checks pass, site builds, and the promotion script round-trips.

extract_rules.py stamped a new rule with the most recent tag, which names
the previous release. Every entry in the catalogue was one release early:
the 66 rules claiming rc.1 first shipped in rc.2, the 7 claiming rc.2
shipped in rc.3, and the 15 claiming rc.3 have not shipped at all.

A new rule now records 'unreleased' and promote_since.py resolves it when
a release is tagged, because the number is not knowable while authoring.

Also bumps the validator pin from 0.18.1, which has no reference_properties
and emits no @embed @Never, so CI gated the release with a validator that
predates the rule it was checking.
@simontaurus
simontaurus merged commit 50d75fb into main Sep 21, 2026
3 checks passed
@simontaurus
simontaurus deleted the fix/since-stamp-and-validator-pin branch September 21, 2026 05:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant