Api Platform Extra Laravel Package

Product Decisions This Supports

Initial assessment for v0.2.0. The release is meaningful because it changes compatibility expectations and configuration behavior, so treat it as an early-stage dependency evaluation rather than a routine patch.

• Build vs. buy / adopt vs. defer: Supports a decision to evaluate the package for Laravel roadmap needs, but v0.2.0 remains pre-1.0. Adoption should be scoped to a pilot or non-critical path until compatibility and upgrade behavior are proven.
• Laravel/Symfony compatibility planning: Bumping the minimum Symfony version to 4.4 and adding 5.x support affects which Laravel versions and dependency sets can use the package. This should feed directly into the supported-version matrix and upgrade planning.
• Configuration and rollout strategy: “All configuration is now opt-in” is a product-relevant behavior change. It reduces hidden side effects but increases setup burden. Teams should plan explicit enablement, documentation, and migration checks for existing integrations.
• Release gating: Because this is a 0.x release with a configuration-semantics change, adoption should require engineering validation, regression tests, and a pinned version.
• Use cases: Best suited for Laravel applications that need the package’s specific capability, can tolerate early-stage API/config churn, and are willing to explicitly configure behavior rather than rely on defaults.

When to Consider This Package

Consider it when:

• The application’s Laravel/Symfony dependency set is compatible with Symfony 4.4 or 5.x, and the team has verified the exact Laravel version matrix.
• The team prefers explicit opt-in configuration and can document the required enablement steps.
• The package’s capability materially reduces custom development effort or roadmap risk.
• The integration can be piloted behind a feature flag or limited rollout before broader production use.
• The team can pin the version, monitor releases, and absorb pre-1.0 changes.

Look elsewhere or defer when:

• The package is intended for a production-critical path and there is no demonstrated maintenance, test coverage, or security/upgrade policy.
• The team needs zero-configuration drop-in behavior; v0.2.0 moves in the opposite direction.
• The application requires Symfony 6+ compatibility or a Laravel version outside the package’s validated Symfony 4.4/5.x matrix.
• Existing integrations depend on previous default-enabled configuration and cannot tolerate a migration or behavior audit.
• The package’s domain is not central to the roadmap; the opt-in migration cost may outweigh the benefit.

How to Pitch It (Stakeholders)

For executives: This is a low-commitment evaluation candidate, not a platform bet. v0.2.0 improves compatibility with modern Symfony lines and makes configuration explicit, which can reduce hidden behavior but requires engineering setup. Because it is still pre-1.0, recommend a bounded pilot with clear exit criteria rather than broad adoption.

For engineering: Treat v0.2.0 as a compatibility and configuration migration release. Confirm the Laravel/Symfony support matrix, audit any existing configuration for the new opt-in behavior, pin the version, and add regression coverage before production use. The main risks are pre-1.0 API churn and silent misconfiguration if enablement steps are missed.