Definitely Not V3 Laravel Package

Product Decisions This Supports

• Addon scaffolding: template vs. dependency. This package is an empty Statamic addon skeleton with a joke name — a service provider, PSR-4 autoloading, and a Composer manifest. It supports one narrow decision: when we need to build an extension inside the Statamic control panel, do we start from official scaffolding or copy a minimal pattern? Answer: use first-party make:addon tooling, and treat this repo as a five-minute reference for the shape of the manifest, not as an install target.
• De-risking estimates for "build an addon" roadmap items. The mechanical cost of a Statamic addon is near zero — the repo demonstrates that in four files. Use it to strip the scaffolding line out of an estimate, then put the real cost where it belongs: domain logic, admin UI, permissions, data migration, support burden, and long-term compatibility. Do not let a trivial skeleton make an addon initiative look cheap.
• Versioning and changelog policy for anything we ship. This is the actual product lesson. The package lampoons version-number confusion in the addon ecosystem, and its own artifacts — a "3.0.2" release whose entire changelog reads "Stuff.", a repo literally named definitely-not-v3 — are the punchline. Downstream consumers read our major/minor/patch numbers as a compatibility contract whether we intend it or not. If we ship extensions, we need a written, boring semver policy and descriptive release notes. A "Stuff." changelog is the failure mode; do not reproduce it in our own artifacts.
• Dependency-intake discipline. The package is archived, last released in 2018, has 4 stars and zero dependents. It is a useful test case for our intake process: does our review catch that a version string and a description can be a bit rather than a promise? Recording an explicit "reference only, not a dependency" decision here prevents a future reviewer from re-surfacing it as a mature 3.0.x library.
• Documentation positioning for developer-facing surfaces. The humor lands because the audience is developers who have lived the version-confusion pain. That is a legitimate signal for internal tooling docs and release notes: personality works when aimed at shared pain and backfires when it replaces content.

When to Consider This Package

Consider it as reference material only:

• You are writing a first Statamic addon and want to see the minimum viable service-provider registration and Composer manifest shape — read it, do not require it.
• You need a cautionary example to anchor an internal conversation on addon versioning, changelog quality, and what "3.0.x" implies to consumers.
• You are forking a disposable internal skeleton under our own namespace, with zero upstream relationship.

Look elsewhere — and you almost always should:

• You need a maintained dependency. Archived since 2018, no dependents, no security patching, no Laravel- or Statamic-version compatibility work, no maintainer to ask. The stated modern compatibility in its description is copy from the era it was written, not a verified constraint.
• You need it to do anything. It ships no features. Adopting it adds a zero-value node to the dependency graph while removing our ability to change it.
• First-party tooling already covers this ground. Current Statamic ships addon scaffolding. When the framework absorbs a package's entire reason to exist, the package is a history lesson — and this one has been superseded twice over.
• You are on a supported Statamic/Laravel version. The manifest constraints will be stale; correcting them takes longer than writing the provider from scratch.
• You want the joke in composer.json. A joke dependency is indistinguishable from an accident six months later, when nobody remembers why it is there and everyone is afraid to remove it. Fine as a link in an onboarding doc; not fine in a manifest.

How to Pitch It (Stakeholders)

For executives: This is not a dependency we should adopt, and ignoring it costs us nothing. It is an archived 2018 joke package — an empty starter template for a Statamic addon, published under a name that mocks the ecosystem's version-numbering confusion, with four stars and no downstream users. The takeaway is not the package; it is the question it surfaces: do we have a written versioning and changelog policy for anything we ship or extend? If an engineer proposes adding it, treat that as a prompt to confirm we are on current first-party scaffolding, not as a procurement request. Recommendation: reference only — do not add it to the dependency register, and record the decision so it does not get re-litigated next quarter.

For engineering: Read the repo, do not require it. It is the minimum Statamic addon shape — composer.json with PSR-4 autoloading, an auto-discovered service provider, nothing else — and if that shape is useful, copy it into a repo where we control the constraints. Anything we actually build should start from current official scaffolding, because this manifest has not tracked a Laravel or Statamic release since 2018 and its compatibility claims are unverified. The one thing worth carrying forward is the premise: our addon releases need descriptive changelogs and a versioning policy we can point at, since consumers will read our major/minor/patch numbers as a promise. Next step: close the adoption question inside an hour — one engineer skims the repo as a template reference, confirms we are on current first-party tooling, and records "reference only, not a dependency" with a one-line rationale. Reinvest the saved time in a changelog and versioning convention for our own extensions.