Fleetbase PHP SDK 1.2.0
Fleetbase PHP SDK 1.2.0
Version 1.2.0 syncs the locked contract to Postman 9b59bef and adds the fleet membership endpoints Fleet-Ops introduced in its public Fleet resource expansion.
Highlights:
- four new methods —
assignDriverToFleet,assignVehicleToFleet,removeDriverFromFleet, andremoveVehicleFromFleet— coveringPOSTandDELETEon/fleets/:id/drivers/:driverand/fleets/:id/vehicles/:vehicle; - the locked collection grows from 220 to 241 requests, all mapped and all covered by the hermetic contract suite;
- contract-only scenario requests no longer become public methods;
- repeated query parameters survive contract generation, so an expansion sent as
?with[]=vendor&with[]=driverdocuments both values.
Scenario requests are documented, not minted
The collection distinguishes an operation from a scenario that exercises one. Twenty-one requests were added upstream, but only four are new operations. The rest retry an assignment to show it is idempotent, create a driver without an email to show contact details are optional, or send an empty relationship to show it is ignored — all through endpoints the SDK already exposes.
Previously every request became a method, which would have published names like createOrderWithEmptyRelationships and removeDriverFromFleetAgain, and would have filed createFleetDriver on FleetService even though it posts to /drivers. Those names would then have been permanent, since the compatibility gates gate removal.
contracts/sdk-variants.json now records which requests are scenarios and which operation each one exercises. Each still appears in the reference and is still driven by the contract suite — through the canonical method, which is the claim worth testing: the scenario is reachable with the API the SDK already offers. Expand a Vehicle documents retrieveVehicle($vehicleId, ['with' => ['vendor', 'not_a_relation']]), which is what a caller actually writes.
Compatibility
Additive. The working tree is verified compatible with the 1.0.2, 1.0.3, and 1.1.0 public API baselines, and no method published in an earlier version was renamed, retyped, or removed.
Version 1.2.0 is distributed under AGPL-3.0-or-later. Published 1.0.x tags retain the MIT license shipped with those releases.
Merging release/v1.2.0 into main starts the release workflow. It derives version 1.2.0 from the merged branch, reruns the live SDK contract and all release gates, waits for any configured protected release environment approval, and then creates the immutable tag and GitHub Release. No manual version input is used.