Statamic Variable Number Fieldtype Laravel Package

Product Decisions This Supports

• Platform upgrade timing (Statamic 5 → 6): This release is fundamentally an upgrade-enablement release. 3.0.0 adds Statamic 6 compatibility, which means the fieldtype is no longer a blocker on the Statamic 6 migration path — but the major version bump signals the maintainer is treating this as a breaking boundary. Treat it as the go/no-go input for scheduling the CMS upgrade rather than a standalone feature decision.
• Build vs. buy for variable-length numeric input: A fieldtype that stores a variable number of number values is small but non-trivial to build correctly (repeater-style UI, validation, serialization into the content store, fieldtype registration, Vue/CP component). Keeping the dependency is usually cheaper than owning that surface, especially since the CP component must be kept in sync with each Statamic major.
• Roadmap risk, not roadmap feature: There is no new product capability here. The decision this informs is "can we close the Statamic 6 upgrade epic," not "what do we ship next." Do not let it consume roadmap capacity beyond the upgrade workstream.
• Content model durability: Because this is a fieldtype, content authored with it is bound to the addon's storage format. Major-version jumps are the moment to verify stored content still renders and edits identically after upgrade — a data-continuity check, not just a dependency bump.
• Vendor concentration check: Single-maintainer addons that gate a platform upgrade are a concentration risk. Use this release as the trigger to inventory how many other addons are similarly blocking Statamic 6.

When to Consider This Package

• Adopt/keep it when: your content model genuinely needs an arbitrary, user-defined count of numeric values (rate tables, tiered pricing bands, measurement sets), you are on Statamic 5 and planning 6, and the fieldtype's editing UX is already baked into editors' workflows.
• Upgrade to 3.0.0 when: you are moving to Statamic 6. Confirm in a staging branch that 3.0.0 does not simultaneously drop Statamic 5 support if you run mixed environments — the major bump strongly suggests a compatibility break, and the release notes do not state the supported version range. Verify against composer.json before assuming dual support.
• Look elsewhere / build in-house when: you need only a fixed number of numeric fields (native fields or a Grid/Replicator cover it), you need numeric arrays validated against business rules beyond "is a number," or you need a maintained-by-vendor SLA. Also reconsider if you are not on Statamic at all — this package is meaningless outside that ecosystem.
• Pin/monitor when: you are staying on Statamic 5 for now. Stay on the 2.x line and treat 3.x as off-limits until the platform upgrade is approved, since pulling 3.0.0 early risks an incompatible fieldtype in production.

How to Pitch It (Stakeholders)

For executives: A small, single-maintainer addon we rely on for numeric input fields has shipped a major version whose only change is Statamic 6 support. This is good news — it removes one of the last third-party blockers on our CMS upgrade — but it is a compatibility release, not a new capability, and it comes with no product value on its own. The business decision is purely about sequencing the platform upgrade and accepting the residual risk of depending on a one-maintainer package that gates our upgrade path.

For engineering: 3.0.0 adds Statamic 6 support (PR #2). The major version number implies a breaking compatibility boundary, so: (1) confirm the supported Statamic version range in composer.json rather than inferring dual 5/6 support; (2) upgrade the addon and Statamic together in the same branch, never independently; (3) smoke-test existing content — edit and re-save a record using the fieldtype, and verify stored values round-trip; (4) pin 2.x on any environment remaining on Statamic 5; (5) flag this in the addon inventory as an upgrade-path dependency with a single maintainer, and identify any siblings in the same position before committing to an upgrade date.