Upgrade Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy — decided in favor of build. This package is evidence for a pattern, not a procurement. Its value to a PM is as a reference design for an "upgrade runner": a registry of ordered, per-version upgrade scripts plus a command that detects what has already run and executes the remainder idempotently. The decision it informs is "should we fund a small internal upgrade capability?" — not "should we add this dependency?"

• Framework-fit correction before anything else. Despite being filed under a Laravel/PHP review, this is a Symfony bundle (Bundle subclass, DI extension, Symfony console command). Laravel has no equivalent bundle lifecycle, so there is no drop-in path; adopting it on Laravel means a bespoke translation layer around unmaintained internals. This is a signal that the package was shortlisted by name match, not stack match — worth flagging to the requesting team before spending more time on it.

• Roadmap prioritization and support-cost framing. Version skew manifests as tickets, manual runbooks, and failed upgrades. If those costs are measurable (self-hosted/on-prem customers off your release cadence), an upgrade runner is a defensible roadmap item. If you ship continuously to SaaS and migrate forward once, the entire problem class disappears and the roadmap item is not warranted.

• Use cases the pattern maps to: multi-hop upgrades (v1 → v4 in one operation), non-schema data migrations, config/env rewrites, filesystem moves, deprecation and API bridging, and post-install steps that Composer scripts can't sequence safely or re-run idempotently.

• Where it does not apply: continuous-delivery SaaS, modern framework baselines, and any case where the only real need is schema change (Doctrine/Laravel migrations already own that) or automated code upgrades (Rector).

When to Consider This Package

Consider it only as a design reference — a one-hour read — or if you are already pinned inside the Modera ecosystem (Modera Foundation / Modera 3.x-era Symfony 2 applications) with a maintainer willing to fork and own the code.

Look elsewhere — or don't adopt at all — when any of these hold:

• You are on Laravel. The package targets Symfony's bundle contract and console tooling. There is no service provider, facade, publishable config, or artisan command, and there never will be. Out of scope by construction.

• You are on a current stack (Symfony 4+, PHP 7.2+). Last release was 2016-06-10; compatibility is very likely broken and untested. Expect breakage in service wiring, console command signatures, and event dispatch.

• You need vendor support, security responsiveness, or a documented upgrade path. The repo is archived/read-only, zero stars, zero dependents — no upstream to file issues against, no CVE feed, no community safety net.

• Nobody on the team will own a fork. An unmaintained dependency with no owner is a future incident, and a fork converts every future framework upgrade into an internal patch obligation.

• A better-fitting tool covers the actual job: Doctrine/Laravel migrations for schema, Rector for code-level upgrades, framework recipes and official upgrade guides, Composer post-update-cmd scripts, or a small in-house command (a version ledger plus ordered, idempotent scripts) — realistically about a sprint, with tests and current framework support.

Default recommendation: do not add as a dependency. Read it, extract the pattern, build the small thing yourself.

How to Pitch It (Stakeholders)

To executives: This is not a dependency we should adopt. It is an archived, zero-adoption package last released in 2016 — no maintainer, no security response, no upgrade path — and it would impose legacy-framework constraints on our stack in exchange for roughly a week of saved engineering. It is also a Symfony bundle, not Laravel, so there is no drop-in path for us regardless. What is worth attention is the problem it names: customers running old versions and upgrading painfully cost us support hours and create failed-upgrade incidents. Recommendation: skip the package; if that pain is measurable, fund a small internal upgrade runner as part of the platform. The package's approach is a one-hour reference read, not a procurement.

To engineering: The mechanism is simple and worth stealing — a registry of per-package, per-version upgrade scripts plus a command that detects installed versions and executes the correct sequence idempotently, with a durable record of what has already been applied. We can implement the equivalent natively on our own stack, with tests, current framework support, and clear ownership, in about a sprint. Treat the repo as prior art, not a dependency. Two design choices to make deliberately:

• Where scripts live. This bundle assumes upgrade scripts ship inside each package, which couples packages to the orchestrator and to our release process. Decide between that and a central, version-keyed script registry before we build.
• Failure semantics. Design against partial application (no transaction boundary), non-idempotent re-runs, silent no-ops from version comparison mismatches (string vs. semver, prerelease tags), nondeterministic ordering when two packages claim the same target version, and Composer post-update hooks that mutate files and conflict with composer.lock verification in CI. Record applied steps in a ledger and fail loudly, never silently.

Bottom line for the roadmap: do not adopt modera/upgrade-bundle. Treat it as a design reference. The underlying need is legitimate; the artifact is not viable, and nothing here is blocking.