Laravel Gedcom Laravel Package

Product Decisions This Supports

• Build vs. buy on genealogy import/export. GEDCOM 5.5.1 is a deceptively messy spec — encoding quirks (ANSEL), non-standard vendor tags from Ancestry/FamilySearch/MyHeritage, and free-text date parsing. A maintained package that already absorbs that complexity is almost always cheaper than a first-party parser, and v8.6.0's changes are maintenance-shaped, not feature-shaped, which is what you want to see in a dependency you don't intend to fork.
• Data portability as a retention and acquisition feature. If the roadmap includes onboarding users by importing an existing tree, or letting users export and leave, GEDCOM read/write is the enabling capability. Both directions matter: import is a growth lever, export is a trust/compliance lever (data portability expectations, GDPR-style access requests).
• Extensibility without forking. The GedcomGenerator change resolves Source through the Laravel service container rather than instantiating it directly. That means you can bind your own Source implementation — custom repository metadata, provenance/audit info, house-specific identifiers — from a service provider. For a PM this is the difference between "configure it" and "maintain a fork," and it's the single most decision-relevant line in this release.
• Framework upgrade runway. The CI change pins the host and admits Laravel 13 into the test matrix. If your platform's upgrade cadence outruns your dependencies, this is the signal that tells you this package won't be the thing blocking your next major Laravel bump.
• Roadmap scoping / risk register. A release containing only CI hygiene and one DI fix is a stability release. It supports a decision to adopt the package as stable infrastructure, and it argues against expecting upstream to deliver product features for you — anything beyond spec-compliant parse/serialize is your build.

When to Consider This Package

Consider it when:

• You are on Laravel and need GEDCOM 5.5.1 parse and/or generate in PHP, and you'd rather not own the spec's edge cases.
• You need container-level customization of generated output (the new Source binding is exactly this hook) — for provenance, multi-tenant labeling, or custom source citations.
• You want a dependency that tracks upcoming Laravel majors rather than pinning to the version it was born on.
• Your use case is import/export of standard GEDCOM; you are not asking the package to be your genealogy domain model.

Look elsewhere — or budget for in-house work — when:

• You need GEDCOM 7, or heavy support for vendor-proprietary extensions. Nothing in this release suggests that surface is expanding.
• You need guaranteed SLA-backed support. Two first-time contributors landing a CI fix and a DI fix is healthy community activity, but it is not a vendor support contract. Bus-factor and maintainer-depth risk is real and should be recorded as such.
• You need a turnkey tree UI, relationship-resolution engine, or media pipeline. This is a format library, not an application.
• Your stack isn't Laravel/Composer-adjacent; the value here is partly framework integration, and that leverage disappears outside it.

Worth stating plainly: this release is two pull requests, both from new contributors, one of which only affects CI. That's a positive maintenance signal (the project is alive, the test suite is being kept honest, and new people can get patches merged) but a thin evidence base for a production commitment. Before adopting, verify the pre-8.6 baseline yourself: check test coverage against real-world GEDCOM files from the vendors your users actually use, and confirm behaviour on ANSEL-encoded input.

How to Pitch It (Stakeholders)

For executives: We need to read and write GEDCOM, the standard file format every genealogy product exports. Building that ourselves means owning decades of format quirks from Ancestry, FamilySearch, and others — a recurring cost with no product differentiation. This package is an established Laravel library that already handles it. The latest release shows the project is actively maintained and being prepared for the next major Laravel version, which lowers the risk that it blocks a future platform upgrade. Recommendation: adopt as a dependency, keep import/export on the roadmap as a growth and data-portability feature, and treat it as commodity infrastructure rather than something we invest in building.

For engineering: v8.6.0 is a maintenance release — no new features, no breaking changes, no deprecations. Two things matter. First, GedcomGenerator now resolves Source through Laravel's service container, so you can bind a custom implementation via a service provider instead of patching vendor code; use that for provenance and tenant-specific source metadata rather than forking. Second, CI now pins the runner host and exercises the suite against Laravel 13, which is our forward-compatibility signal for the next major upgrade. Note that both PRs came from first-time contributors, so treat the project as community-maintained: pin the version, review release notes on each bump, and wrap the library behind a thin internal interface so we retain the option to swap it. Before committing, we should validate against a corpus of real vendor exports — particularly ANSEL-encoded files — since that's where GEDCOM integrations historically break.