Afip Bundle Laravel Package

Product Decisions This Supports

• Framework upgrade planning: v1.2 adds Symfony 5 support, which unblocks adoption on Laravel 6+/Symfony 5-era stacks and directly informs whether this package can stay in our dependency graph through the next framework upgrade cycle.
• Build vs. buy / dependency triage: The release is small and maintenance-oriented (compatibility plus a maintainer-namespace change), which is evidence for the "buy/keep" side only if the package's functionality is non-core; it is not evidence of active feature investment.
• Roadmap risk flagging: The Gonzakpo → Gonzaloalonsod change is a vendor/namespace rename. This is a breaking change for consumers — Composer package name, service-provider registration, and any use Gonzakpo\... imports may need updating. It feeds a migration ticket and a version-pinning decision in our backlog.
• Use cases: Relevant where we need the package's capability on Symfony 5-compatible applications; not a differentiator for greenfield work where a first-party or better-maintained alternative exists.

When to Consider This Package

• Adopt when: (a) you are on a Symfony 5 / Laravel 6+ stack and need exactly this capability; (b) you can pin to an explicit version and absorb a one-time namespace migration; (c) the package has a single, narrow responsibility you could otherwise write in a day.
• Look elsewhere when: you need a documented support matrix (the release notes do not state whether Symfony ≤4 support was dropped — treat v1.2 as potentially breaking on older Symfony), an actively maintained project with a changelog and semver discipline, or a package whose maintainer identity is stable. The publisher rename in a minor version (1.2) is a semver smell: either the Composer package name changed (requiring a composer require update) or only the PHP namespace did (requiring code edits). Confirm which before committing.
• Do not adopt on the strength of these notes alone — v1.2 contains no new functionality, and the compatibility claim is unverified against your CI matrix.

How to Pitch It (Stakeholders)

For executives: This is a maintenance release, not a feature release. It keeps the package compatible with Symfony 5 and renames the maintainer's namespace from Gonzakpo to Gonzaloalonsod. The practical impact is a small, scheduled migration (Composer/import updates), not new capability — so it should be treated as technical-debt housekeeping with a known, bounded cost.

For engineering: Upgrade path is v1.2, which introduces Symfony 5 support and a namespace change. Verify (1) the Composer package name and whether a replace/alias exists, (2) whether older Symfony versions were dropped, and (3) test-suite coverage on our target PHP version. Treat this as a minor version with breaking potential — pin the version, run the migration in a branch, and confirm the upstream repo/author is the legitimate continuation before updating lockfiles.