Elasticsearch Bundle Laravel Package

Product Decisions This Supports

• Precision-dependent features. The headline of v6.0.4 is that a result score can now be returned as a float rather than an integer. That is an enabling change, not a cosmetic one: it unlocks product surfaces where whole-number granularity was the blocker — relevance/match rankings with meaningful tie-breaking, risk or fraud scores thresholded at values like 0.82, percentile and tier bands, quiz/assessment partial credit, and experiment metrics that need sub-unit resolution.
• Roadmap sequencing. Anything previously deferred with the note "waiting on finer score granularity" can be re-scored for the next planning cycle. Expect a modest but real reduction in estimated effort for ranking, tiering, and graded-scoring roadmap items.
• Build vs. buy. A live, additive patch on the v6 line is a maintenance signal. It argues for staying on the package rather than building a bespoke scorer in-house — the cost of ownership for a custom implementation is hard to justify when the vendor is still shipping capability into the existing major version.
• Release risk triage. This lands as 6.0.4, a patch number, yet adds a capability. That is a semver inconsistency worth flagging: consumers reasonably assume patches are behavior-neutral. Treat it as a low-risk but non-trivial change and verify downstream type assumptions rather than waving it through on the version number.
• What this release does not answer. Return type says nothing about score accuracy, calibration, determinism, or explainability. If your roadmap depends on any of those, this release is not evidence either way — those remain open questions for the package maintainers.

When to Consider This Package

Adopt / upgrade when:

• You already depend on the package and any product surface displays, ranks, thresholds, or persists a score.
• Your requirements include fractional scores and you are currently rounding integers at the boundary (a common source of visible inconsistency between screens).
• You are on a v6 release and can absorb an additive change inside your normal patch cadence.

Look elsewhere, or pause, when:

• You need documented precision guarantees, an explicit rounding policy, or locale-aware score formatting. A float return type without a stated precision contract invites display drift across platforms.
• You persist scores. Switching from an integer to a float/decimal column is your migration, not the package's — plan schema, backfill, and any int casts in models or DTOs before upgrading.
• Deterministic equality matters. If code compares scores with === or keys caches/idempotency on exact score values, float representation will surface latent bugs; move to epsilon comparisons or fixed-precision decimals.
• You need score explainability or auditability (regulated scoring, credit, eligibility). Nothing here addresses that; evaluate a purpose-built solution or keep the scoring model in-house.

How to Pitch It (Stakeholders)

For executives: This is a small, additive release with no breaking changes and no forced migration. It removes a precision ceiling that was constraining several candidate features, which slightly improves the cost case for staying on the package instead of building a scorer ourselves. Risk is low; the only work is a short verification pass on our side. Recommendation: upgrade on the normal cadence, no dedicated project needed.

For engineering: The package can now return a float score. Confirm the new return path is opt-in and that existing integer behavior is unchanged. Audit every consumer of the score: model casts, database column types and any backfill, serialization/API contracts, cache keys and equality checks, and tests that assert exact integer values. Note the semver oddity — a feature shipped under a patch version — so treat it as a behavior change in review rather than a routine bump.