Getting Started

0.1.29 is a maintenance release: it refreshes ixnode dependencies. No new features, deprecations, or breaking changes are documented, so treat it as a dependency-bump release and pin to ^0.1 until you have regression coverage.
Look first at README.md, composer.json, CHANGELOG.md, src/, tests/, and any DependencyInjection/ or service-provider files. The package is named as a “Bundle”, so verify its registration path before assuming Laravel auto-discovery.
Minimal setup: composer require ixnode/php-api-version-bundle:^0.1, register the service provider/bundle bridge if needed, publish config if supported, and clear Laravel’s config/route caches.
First use case: configure one supported API version and expose either a small /api/version endpoint or a version-gated route group. Verify the resolved version and response before adding multiple versions or negotiation rules.

Implementation Patterns

Keep supported versions, default version, and deprecated versions in config as the single source of truth.
In Laravel, wrap the package’s version resolver in middleware: parse Accept or X-Api-Version, validate against config, attach the resolved version to the request, and reject unsupported versions with a consistent error response.
Bind any package service into Laravel’s container explicitly rather than relying on Symfony-style container conventions.
Use a version endpoint to report current, supported, and deprecated versions from the same config used by middleware.
Prefer route groups per API version or version-aware controllers that delegate to version-specific actions. Avoid scattering version checks through controllers.
Add tests for default resolution, explicit version, invalid version, deprecated version, and fallback behavior.

This is a 0.x package: pin versions and run regression tests after dependency updates. 0.1.29 only updates ixnode packages, but transitive dependency changes can still affect behavior.
The “Bundle” naming may mean Symfony-style registration. In Laravel, confirm whether auto-discovery works or whether you need a manual provider/bridge.
Clear config and route caches after changing version configuration; stale caches can make middleware resolve old defaults.
Define header precedence and fallback rules explicitly: Accept vs X-Api-Version, default version, and unsupported-version behavior should be documented and tested.
Do not hardcode the “latest” API version in controllers; resolve it from config so future version additions do not require controller edits.
Debug with container resolution checks, php artisan route:list, and resolver logging. Useful extension points are usually a custom version resolver and response middleware/listener.