Skip to content

Release 1.4.1 - #18

Merged
roncodes merged 1 commit into
mainfrom
release/1.4.1
Sep 14, 2026
Merged

Release 1.4.1#18
roncodes merged 1 commit into
mainfrom
release/1.4.1

Conversation

@roncodes

Copy link
Copy Markdown
Member

Tracks the inspection API's renamed submission answers, which landed upstream after 1.4.0 was published.

Supersedes #17, which was cut as release/1.4.0 before I checked the tags. 1.4.0 is already released — tagged at f8237cc, which is main's HEAD, published on GitHub and live on Packagist — so release.yml would derive version 1.4.0 from the branch name and check-release-version.php would refuse the tag as already existing. CI caught this too: #17's "Release candidate dry run" failed at Validate release identity and dependency security, while every other check passed. This is a patch on top of 1.4.0, so it is 1.4.1.

What changed

A submission's answers were custom_field_values, each naming its field with custom_field. The API calls them answers and field now — that is what it documents and what it returns — and a field is named by a public id rather than a bare uuid. The earlier spellings are still accepted on submit, so this is additive and breaks no existing integration.

The SDK forwards a submission body verbatim, so no src/ file names any of these keys and none needed rewriting. What changed is the locked contract and everything generated from it, plus the hand-written pieces: the README example, the submission test's payload and response fixtures, the dated changelog section and docs/releases/1.4.1.md.

The generated submit example previously sent an empty custom_field_values beside a populated flat item_results block — the only worked example in the reference was the legacy shape. It now answers the way the API documents.

Pins

  • postman822b867 (the collection rename and its response examples, both merged)
  • fleetopsrefs/pull/319/head @ 9f2ffe98

As in 1.4.0, the upstream implementation is still Fleet-Ops PR #319; release approval must confirm its API is available in the intended deployment. A passing overlay run proves the locked implementation, not availability in every published image.

Checks

composer check passes locally: PHPStan clean, PHPUnit 41 tests / 4749 assertions, contract manifest 270 requests with 270 mapped and 0 unmapped, 38 service groups, 270 executable examples, licence metadata verified, and API compatibility confirmed against 1.0.2, 1.0.3, 1.1.0, 1.2.0 and 1.3.0.

php tools/check-release-version.php 1.4.1 reports Release version 1.4.1 verified against latest tag 1.4.0.

On #17 the live Postman/SDK contract passed (11m17s) with "answers": [] in the asserted response, so the rename is verified end to end through the SDK bridge.

docs/api-coverage.md shows every row changed: each embeds the locked Postman commit in its source links, so repinning rewrites all 270 lines. The request set, services and statuses are unchanged.

1.4.0 shipped before the upstream rename landed, so this is a patch on
top of it rather than a change to a published release.

A submission answers with `answers`, each entry naming its `field` by
the public id the form hands out; `custom_field_values` and
`custom_field` are still accepted on submit, so nothing integrating
against an older deployment breaks.

The SDK forwards a submission body verbatim, so no src/ file names these
keys. This repins the locked contract at the merged collection and
regenerates what follows from it, and updates the hand-written pieces:
the README example, the test payload and response fixtures, the dated
changelog section and the release note.
@roncodes
roncodes merged commit 6ca0c25 into main Sep 14, 2026
31 checks passed
@roncodes
roncodes deleted the release/1.4.1 branch September 14, 2026 09:42
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