This help centre explains how to use dFlow and how to migrate from legacy concepts.

Release notes and changelogs summarise what shipped in each version. Use both: one for tasks and mental models, the other for “what is new this week.”

Public changelog (marketing site)

Shipped product updates are summarised on the public site:

• dFlow changelog: high-level feature and fix announcements.

That page is aimed at all visitors; it may not list every internal migration flag or Payload migration name.

Self-hosted operators

When you run the control plane yourself:

• Track dashboard and core package versions you deploy; migrations under apps/dashboard/src/migrations/ (for example projects → applications and service ownership normalisation) ship with those releases.
• Read docs/projects-to-applications-rollout.md and docs/normalize-service-ownership-migration.md in your checkout for operator procedures that align with the customer-facing Migrate from legacy Projects to Applications guide.

This documentation package

• packages/docs/manifest.json versions the customer doc set (version bumps when structure or pages change materially). It is not the same as the application semver.
• Migration and Release Notes in the sidebar is the right place for long-lived migration guidance; the marketing changelog is the right place for time-ordered headlines.
• Databases and Templates are first-class sidebar sections. Their manifest.json owner fields (parallel-databases-writer, parallel-templates-writer) mark content ownership; navigation order still follows IA.md and root meta.json so readers see one coherent tree.
• Product model background for Applications vs legacy Projects lives under Product model changes; shipped feature headlines stay on dFlow changelog.

Related

• What changed in dFlow: hub for model and docs changes.
• Documentation migration notes: legacy help centre and this package.