0.7.0 — two distributions, one 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
--jsonis 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 ownpath. A consumer readingjson.load(f)["findings"]now readsjson.load(f)[0]["findings"].vdi2770.read_pdf(...).is_pdfis now three-valued —True,False, orNone.Nonemeans the object scan gave up without deciding; 0.6.0's field was a plainbooland could not say so. A naiveif facts.is_pdf:now takes the false branch on a file it used to accept — useis True/is False.MAX_OBJ_PROBESis new in 0.7.0, at100_000: how many occurrences ofobjthe reader examines before answering not known rather than no.rulesprintsobligation=where 0.6.0 printedbasis=— same value, new word.- Every JSON entry now carries
schemaVersion,toolVersionandvdiSchema, including an entry for a path that could not be read. Key your consumer offschemaVersion: 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.0Upgrading 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.zipsha256 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.