📦 WP-159 — release: v0.7.0 augmentation engine upstream¶
Engineering log · Phase 14 — Augmentation upstreaming to
fuse, v0.7.0
WP-159 — the release that cannot be published, and why that was the better half¶
__version__ moves 0.6.0 to 0.7.0, which is the whole of the version change — pyproject.toml declares the version dynamic and reads the module attribute. [Unreleased] closes as [0.7.0]. make freeze-goldens MINOR=0.7 copies seven live metric sets into goldens/frozen/0.7/, the same seven 0.6 holds since WP-154c taught the mechanism to skip the two generator-derived goldens, and 43 goldens pass where 36 did before the freeze.
The fourth clause could not be executed as written, and finding that out was the row's real work. ADR-005 gates promoting fuse-augmentations to a runtime dependency on four conditions, the first being real SemVer releases to PyPI. Measured against PyPI's own API rather than recalled: the latest fuse-augmentations there is 0.10.0.dev0, there is no 0.11 or 0.12 at all, and all eleven releases are .dev0 pre-releases. The floor this phase stands on is a5a276a. Half of that was already written down in pyproject.toml before the row opened — PyPI forbids re-uploading the 0.10.0.dev0 version string — which is worth noting on its own: the blocker was legible in the tree for five work packages and nothing surfaced it, because scripts/release_guard.py checks the tag, the changelog section and the gate, and has no notion of dependency tiers.
What made refusal the worse option is that ADR-005's own fallback expired. The ADR says a refusal "returns the dependency story to a SHA pin, which keeps the augmentation stack local rather than making it unpublishable". That sentence was true when it was written and is not true now: data/affine.py, data/augment.py, data/letterbox.py, data/mosaic.py and data/rotated_aug.py all import fuse_augmentations at module level, so lucid_yolo.data — and predict, through letterbox — cannot import without it. The stack is not local any more, so refusing promotion returns nothing; it leaves the package in the dev group, where every install omitting that group yields a distribution that fails at import. The choice was never "publishable or not". It was "unpublishable, or broken for anyone who installs it without a development group", and those are not symmetrical.
Condition 1 is therefore recorded as knowingly failed rather than quietly satisfied. The pin moves into [project].dependencies as a direct reference, which is legal to build and install and illegal to upload, so the distribution is unpublishable to PyPI. That costs nothing this project currently does: release.yml states in its own header that publication is an unmade [PRINCIPAL] decision and deliberately omits it, so there is no upload for the rejection to break. Conditions 2, 3 and 4 are met and each was checked rather than asserted — the exact SHA is a stricter ceiling than the range condition 2 asks for; the promotion landed in its own work package whose licence audit was run and now places fuse-augmentations in the republished base tier beside hotcoco, clean at 107 distributions and 344 shipped binaries; and D20 with the docs/ESCALATION.md entry is the record condition 4 asks for. The principal was shown three alternatives — hold the release for PyPI, split the promotion into a later row, or stop — and chose this one. The remedy is small and dated: the day a 0.12 reaches PyPI, a >=0.12,<0.13 range replaces the SHA and nothing else here changes.
What this release does not claim. No tag is cut and no distribution is published, as at 0.4.0, 0.5.0 and 0.6.0 — four release commits now stand ahead of the train's own tags. The contributor-admission rows WP-141 through WP-144 are still unstarted, WP-141 being a principal row whose three preconditions sit outside the roadmap, so Phase 14 ships with the same four-row tail Phase 13 did. A68, A69 and A70 remain open. No trained weights ship (D14). And the phase's subject is a boundary rather than a capability: nothing in 0.7.0 detects anything 0.6.0 could not, and the case for it is that the augmentation engine is now one implementation maintained in one place, with 43 goldens and a four-tier guard standing where the second copy used to be.