Weave Code
Version Bundle Laravel Package
netbrothers-gmbh/version-bundle
NetBrothers VersionBundle helps Symfony apps centralize and expose application version/build metadata. Configure a version once and access it in services and Twig templates for easy display, diagnostics, release tracking, and consistent version reporting across environments.
Trigger based version tables with MariaDB/MySQL and Doctrine
Frequently asked questions about Version Bundle
- How do I install and register netbrothers-gmbh/version-bundle?
- Install it with Composer using composer require netbrothers-gmbh/version-bundle. Because it is a Symfony bundle, it must be registered in your kernel or bundles.php, or enabled through Symfony Flex if a recipe is available. After registration, publish or create the bundle configuration so the version value can be resolved. The package is intentionally small, so setup is limited to registration plus a version setting.
- How do I display the application version in a Twig template?
- The bundle exposes the configured application version so it can be rendered directly in Twig templates, typically in a footer, about page, or build badge. Use the Twig helper or variable documented by the bundle to output the version string. Because the value is centralized, changing the configured version updates every template and service that reads it. This avoids hard-coded version strings scattered across layouts.
- What PHP and Symfony versions does VersionBundle v4 require?
- Version 4 raises the minimum runtime to PHP 8.4 and targets Symfony 7.4 and Symfony 8. That means every environment, including CI runners, Docker images, queue workers, and scheduled-task hosts, must be on PHP 8.4 or newer before you can install it. If your fleet is still on PHP 8.3 or earlier, stay on the v3 line. Confirm the exact constraints with composer why-not before planning the upgrade.
- Does NetBrothers VersionBundle work with Laravel?
- The package is a Symfony bundle, so Laravel integration is indirect rather than native. Laravel releases ship Symfony components, so whether the bundle can co-install depends on the Symfony version constraints your Laravel version resolves. In practice, Symfony 7.4 alignment corresponds to Laravel 12 and later, while Laravel 10 and 11 resolve older Symfony components and will not satisfy v4 constraints. Verify with a composer why-not check in your actual application rather than assuming compatibility.
- Why does composer require fail with Symfony 7.4 or 8 constraint errors?
- The most common cause is that your installed Laravel or Symfony version pulls in Symfony components older than 7.4, so the v4 constraints cannot be satisfied. Another cause is a PHP runtime below 8.4, which blocks resolution even when Symfony components would otherwise match. Run composer why-not netbrothers-gmbh/version-bundle to see exactly which package or platform requirement is holding it back. Fixing the PHP baseline or the framework major is usually the only path forward.
- Can I still extend or mock VersionBundle classes now that they are final?
- Version 4 marks service and command classes as final, which is a hard backwards-compatibility break with no deprecation runway. Any downstream code that extends a package service, decorates a command, or uses PHPUnit createPartialMock or getMockBuilder against those classes will fail at compile time or in tests. Before upgrading, grep your application and internal packages for extends statements and partial-mock calls that reference the bundle namespace. If you genuinely need customization, check whether the package publishes interfaces or abstract contracts you can bind instead of subclassing.
- How do I configure a different version source per environment?
- The bundle supports configuring where the version value comes from, so you can set a release tag in production and a development marker locally or in staging. Keep the value in environment-specific bundle configuration rather than duplicating strings in services or templates. This keeps diagnostics and UI output consistent while still distinguishing builds across environments. Consult the bundle documentation for the supported configuration keys before rolling your own.
- Is there a maintained v3.x branch if I cannot move to PHP 8.4 yet?
- Teams blocked on PHP 8.4 or on Laravel 10 and 11 should pin to the 3.x line and avoid attempting the v4 upgrade. Confirm directly on the repository whether v3.x receives security fixes and for how long, since that window determines your real deadline. Treat a maintained branch as a bridge, not a destination, and plan the PHP baseline work in parallel. If no maintenance window exists, that risk belongs in your upgrade planning.
- How do I test services and controllers that depend on the version service?
- Inject the version service into your own classes and, in tests, substitute a test double of the package contract or of your own thin abstraction. Because v4 classes are final, PHPUnit partial mocks and getMockBuilder against package classes are no longer viable, so introduce a wrapper interface if you need controllable behavior. Prefer unit tests that assert the version string is surfaced in output rather than asserting on the bundle internals. This keeps your test suite stable across future package major versions.
- What should I check before upgrading from v3 to v4?
- Start with a static audit: grep for extends on the package namespace and for createPartialMock, getMockBuilder, setMethods, and onlyMethods in your test suite to map the real blast radius. Then verify the full Composer constraint set, including PHP 8.4, Symfony 7.4 or 8, and the matching illuminate or laravel framework ranges. Review the migration guide carefully, since its quality determines most of the upgrade cost, and confirm whether it enumerates every class newly marked final. Finally, check for any behavior changes beyond final, such as constructor signatures, container binding keys, config keys, and command signatures.
Weaver
How can I help you explore Laravel packages today?