Verse Laravel Package

Product Decisions This Supports

• Launch and SEO readiness: v0.3.0 makes verse build emit a sitemap.xml covering published pages, articles, archive and tag pages. That removes a manual/third-party SEO step from the launch checklist for content-driven sites, and it is on by default — a "works out of the box" story you can put in a go-live plan.
• Build vs. buy for content sites: this package positions Laravel as sufficient for brochure sites, blogs, docs and marketing pages with file-based content (verse.yaml), without adding a separate CMS or static-site generator to the stack. The sitemap addition closes one of the more common reasons teams bolt on extra tooling.
• Roadmap scoping: if you are deciding whether a content/marketing surface is a "later" item, this lowers the incremental cost of shipping it now — routing plus sitemap plus archive/tag pages are handled by one dependency.
• Configuration as product surface: a single sitemap: false flag in verse.yaml gives you a clear, non-code lever for turning the feature off per environment or per project. Treat verse.yaml as part of your release/config contract.
• Operational hygiene: verse --version now reports the Composer-installed version, and a main checkout prints dev-main (<sha>). That makes it possible to record the exact package build in support tickets, deploy logs and incident reviews — useful for reproducible bug reports.

When to Consider This Package

Adopt when:

• Your content is file-based and mostly static (pages, articles, archives, tags) and you want it inside a Laravel app rather than a separate CMS.
• You need sitemap/SEO basics without another dependency — this release covers that case directly.
• You can tolerate a pre-1.0 API (0.x): minor releases may change behavior, and v0.3.0 itself is a behavioral change for anyone already serving public/sitemap.xml.
• You have a small team and value a single-command build (verse build) over a bespoke content pipeline.

Look elsewhere or delay when:

• You need a database-backed CMS, editorial workflows, roles, or preview/publishing approvals — this is a files-and-config model.
• You need multi-locale sitemaps, per-page priority/changefreq tuning, or sitemap indexing — the release describes a single generated sitemap.xml with published pages only; verify against your SEO requirements before committing.
• You already have an SEO/sitemap package or a hand-maintained public/sitemap.xml. Upgrade risk: the generated sitemap now collides with an existing public/sitemap.xml. Either delete/relocate your file or set sitemap: false. Audit this before bumping the version, and pin the dependency during rollout.
• You require API stability guarantees (post-1.0) or vendor SLAs.

How to Pitch It (Stakeholders)

To executives: a small, targeted release that removes a launch dependency. Content sites built on this stack now ship with a sitemap covering pages, articles, archives and tags by default — one fewer piece of SEO plumbing to buy, build or maintain, and one fewer thing that can be missed at launch. It also makes the package's version precisely traceable in production, which shortens support and incident triage.

To engineering: verse build now writes sitemap.xml; opt out with sitemap: false in verse.yaml. Two things to action: (1) the generated sitemap conflicts with any existing public/sitemap.xml, so choose one owner before upgrading; (2) verse --version now reports the Composer-installed version, and dev-main (f8d2498)-style output for branch checkouts — log this in deploys. Note the package is still 0.x, so pin the version and read changelogs on each bump.