Skip to content

Release 1.4.0 - #17

Closed
roncodes wants to merge 1 commit into
mainfrom
release/1.4.0
Closed

Release 1.4.0#17
roncodes wants to merge 1 commit into
mainfrom
release/1.4.0

Conversation

@roncodes

Copy link
Copy Markdown
Member

Adds the driver-facing inspection API to the SDK, and tracks the rename that shipped upstream while 1.4.0 was in flight.

Inspections

All six endpoints from the official collection:

  • inspectionForms->listInspectionForms($filters), retrieveInspectionForm($id)
  • inspections->submitInspection($data, $requestOptions), listInspections($filters), retrieveInspection($id)
  • vehicles->listVehicleInspections($vehicleId, $filters)

The rename

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 older spellings are still accepted on submit, so this is additive, not a break.

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, and the release note — each of which now says answers/field and records that either spelling is accepted, so nobody integrating against an older deployment reads this as a break.

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 (collection rename and the response examples, both merged)
  • fleetopsrefs/pull/319/head @ 9f2ffe98

As the existing release note records, 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 on a clean tree: PHPStan clean, PHPUnit 41 tests / 4749 assertions, contract manifest 270 requests with 270 mapped and 0 unmapped, 38 service groups, 270 executable examples, license metadata verified, and API compatibility confirmed against 1.0.2, 1.0.3, 1.1.0, 1.2.0 and 1.3.0.

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.

A submission's answers were `custom_field_values`, each naming its field
with `custom_field`. The API calls them `answers` and `field` now, which
is what it documents and what it returns; the older spellings are still
accepted on submit.

The SDK forwards a submission body verbatim, so nothing in `src/` names
these keys and nothing needed rewriting: this repins the locked contract
at the merged collection and regenerates what follows from it. The
generated submit example stops sending an empty `custom_field_values`
beside a flat `item_results` block and answers the way the API
documents.

The hand-written pieces — the README example, the submission test's
payload and response fixtures, and the release note — say `answers` and
`field` too, and record that either spelling is accepted so nobody
integrating against an older deployment thinks this is a break.
@roncodes

Copy link
Copy Markdown
Member Author

Superseded by the 1.4.1 release PR.

1.4.0 is already published — tagged at f8237cc (which is main's HEAD), released on GitHub and live on Packagist. release.yml derives the version from the branch name, so merging this would have check-release-version.php refuse the tag as already existing. That is exactly what the failing Release candidate dry run check here reports; every other check on this PR passed, including the live Postman/SDK contract.

The same commit now sits on release/1.4.1 with a dated changelog section and docs/releases/1.4.1.md, and check-release-version.php 1.4.1 verifies clean against latest tag 1.4.0. Nothing is lost by closing this.

@roncodes roncodes closed this Sep 14, 2026
@roncodes
roncodes deleted the release/1.4.0 branch September 14, 2026 09:46
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