Skip to content

0.7.0 — two distributions, one release

Choose a tag to compare

@dev365code dev365code released this 06 Sep 11:05
· 214 commits to main since this release

vdi2770-validate 0.7.0

Two distributions, one release. From 0.7.0 the rules (vdi2770-validate) and the reader (vdi2770) carry the same version, ship under one tag, and the rules name the reader exactly — vdi2770==0.7.0, never a range. Nothing you type changes: pip install vdi2770-validate, the vdi2770-validate command and import vdi2770_validate are all as they were, and pip install vdi2770 still gets the reader on its own, with no dependencies.

Why the range had to go

vdi2770-validate 0.6.0 asked for vdi2770~=0.4.0. A compatible-release clause on 0.4.x is a ceiling as well as a floor, so readers 0.6.0 and 0.6.1 sat on the same index unreachable: installing 0.6.0 gave you reader 0.4.0, and a fix published for the reader could not arrive. The range was later tightened to 0.6.2 — a reader version that was never published at all, so the pin could not resolve on the day it shipped.

An exact pin cannot go stale quietly. One tag names one pair.

⚠️ Upgrading from 0.6.0 will turn some green runs red

This is the tool becoming honest, not stricter. Nothing that passed 0.6.0 has become non-conformant. Five rules can flip a run:

Rule Change about What it means for you
Z10 now also reports two members that are one file where case is not kept apart container B.pdf beside b.pdf is one file on macOS as it ships and on Windows by default — the recipient keeps whichever their unzip tool wrote last. 0.6.0 said F2 about the second member: a warning, exit 0. A sender who followed F2's remedy and declared both got a clean report for a delivery that loses a file.
Z13 new error tool documents delivered as folders. This tool does not open them, and says so: "1 of the errors is this tool declining to look, not the container." Zip each document folder into its own .zip member if you want them checked.
Z6 warning → error tool containers nested deeper than this tool will open.
X6 new error tool a read budget was spent before a model could be built, so the rules that needed it stayed silent and X6 says why.
Z5 now reachable from the PDF layer tool fires when a delivery spends this read's whole budget for inflating PDF streams.

(X5 is new and an error too, but no container can ask for it — it fires only when a rule in this tool raises.)

Important

about is new. Every finding now says about: container (your file is wrong) or about: tool (this tool declined to look). Four of the five above are about: tool — the exit code does not distinguish the two, so a CI job that gates on the exit code alone will fail on a delivery nothing is wrong with. There is nothing to read in 0.6.0's output beforehand: upgrade, then gate on about, or triage those four ids. Z10 is the one that is about your delivery, so filtering the tool axis will not hide it — and it should not.

Breaking changes for consumers

  • --json is now a single array. 0.6.0 printed one JSON document per path; 0.7.0 prints one array with an entry per path, each carrying its own path. A consumer reading json.load(f)["findings"] now reads json.load(f)[0]["findings"].
  • vdi2770.read_pdf(...).is_pdf is now three-valued — True, False, or None. None means the object scan gave up without deciding; 0.6.0's field was a plain bool and could not say so. A naive if facts.is_pdf: now takes the false branch on a file it used to accept — use is True / is False.
  • MAX_OBJ_PROBES is new in 0.7.0, at 100_000: how many occurrences of obj the reader examines before answering not known rather than no.
  • rules prints obligation= where 0.6.0 printed basis= — same value, new word.
  • Every JSON entry now carries schemaVersion, toolVersion and vdiSchema, including an entry for a path that could not be read. Key your consumer off schemaVersion: it moves when a field changes meaning or leaves, never when one is added.

Upgrade

pip install -U vdi2770-validate      # brings reader vdi2770==0.7.0 with it
python -c "import vdi2770_validate, vdi2770; print(vdi2770_validate.__version__, vdi2770.__version__)"
# → 0.7.0 0.7.0

Upgrading over an existing 0.6.0 install is the case this design exists to protect: the two halves move together, so no reader is left behind.

The single-file build

vdi2770.pyz is attached to this release: everything inside one readable zip —
the rules, the reader, the bundled schema and tables, and xmlschema. Nothing
is compiled. It needs a Python and nothing else, which is what a closed network
usually still has when it has no route to a package index.

python vdi2770.pyz check YOUR-CONTAINER.zip
sha256  96160e7b85ec8c5a7793b6c6587993ce6a60526c0e7c4271e05bdcf27f9f7cd8

Built from this tag, and it is an ordinary zip: whoever has to approve software
entering the network can open it and read every line.

Provenance

Both distributions are published from GitHub Actions with PEP 740 attestations. The publisher recorded for this release is dev365code/vdi2770-validate, workflow release.yml, environment pypi-vdi2770-validate. Any file can be checked against it:

https://pypi.org/integrity/vdi2770-validate/0.7.0/<filename>/provenance

Full detail in CHANGELOG.md. A clean run means no error in what we check, never conformant — the declaration stays yours.