---
title: Changelog
description: Publish product updates, release notes, and important changes in a readable timeline.
status: updated
---

## Usage

Use `Changelog` as the timeline container and add one `ChangelogEntry` for each release. Entries accept a date, title, optional version, and optional status.

<Changelog>
  <ChangelogEntry
    date="2026-07-12"
    title="Independent MDX content engine"
    version="v1.2.0"
    status="new"
  >
    Gridlines now owns its complete content pipeline while preserving the same authoring experience.

    - Added automatic page-tree generation.
    - Added frontmatter status badges.
    - Improved documentation image previews.
  </ChangelogEntry>

  <ChangelogEntry
    date="2026-07-05"
    title="Better technical writing components"
    version="v1.1.0"
    status="improved"
  >
    Code blocks, file trees, API references, and tabbed examples now share one consistent visual system.
  </ChangelogEntry>

  <ChangelogEntry
    date="2026-06-24"
    title="Sidebar navigation fix"
    version="v1.0.1"
    status="fixed"
  >
    Fixed active navigation items becoming difficult to find in long documentation sections.
  </ChangelogEntry>
</Changelog>

````tsx
<Changelog>
  <ChangelogEntry
    date="2026-07-12"
    title="Independent MDX content engine"
    version="v1.2.0"
    status="new"
  >
    Gridlines now owns its complete content pipeline.

    - Added automatic page-tree generation.
    - Added frontmatter status badges.
  </ChangelogEntry>
</Changelog>
````

## Status

Use a status when the kind of change helps readers understand the release at a glance.

| Status | Intent |
| --- | --- |
| `new` | A new feature or capability. |
| `improved` | An enhancement to existing behavior. |
| `fixed` | A bug fix or reliability improvement. |
| `breaking` | A change that may require migration. |

The status is optional. Leave it out when a version contains several kinds of changes or does not need extra emphasis.

## Writing useful entries

- Lead with the outcome instead of the implementation detail.
- Keep one release per entry.
- Use lists when a release contains several related changes.
- Add migration instructions directly inside a `breaking` entry.
- Keep dates in `YYYY-MM-DD` format so the rendered date stays predictable.

<Callout title="Keep the newest release first">
  Changelog entries render in source order. Put the latest release at the top so readers can find recent changes immediately.
</Callout>