変更履歴

リリースノートを通常のコンテンツファイルとして書くか、GitHub Releases から取得すると、Blume がタイムラインページと RSS フィードを自動的に構築します。

Blume には変更履歴が標準で用意されています。各リリースを通常のコンテンツファイルとして書き、type: changelog を指定するだけで、Blume がすべてのエントリを収集して生成されたタイムラインページと RSS フィードにまとめます — レイアウトを構築する必要も、リストを管理する必要もありません。あるいはファイルを一切用意せず、GitHub Releases から変更履歴を取得することもできます。

エントリを書く

変更履歴のエントリは、フロントマターに type: changelog を持つ通常の .md または .mdx ページです。慣例として changelog/ 配下に配置しますが、重要なのはフォルダではなく型です:

---
title: v1.2.0
type: changelog
date: 2026-06-20
changelog:
  version: 1.2.0
  category: Features
---

A big batch of components landed this release — columns, frames, trees, and tooltips, plus code groups that render as proper language tabs.

- New `Accordion`, `Expandable`, and `Tooltip` components
- `CodeGroup` tabs with flush code blocks

タイムラインとフィードが新しい順に並ぶよう、すべてのエントリに date を指定してください。クォートなしの YAML 日付でも問題ありません — Blume が正規化します。

changelog オブジェクト

任意の changelog オブジェクトは、タイムラインとフィードにより豊富なメタデータを追加します:

タイムラインページ

type: changelog のエントリが 1 つでもあれば、Blume は /changelog ページを自動的に生成します。サイドバーや目次のない、集中しやすい全幅のタイムラインとしてレンダリングされ、各エントリは新しい順に並び、コンテンツの横の左レールに日付、ラベル、category タグが表示されます:

• エントリのタイトルがそのラベルになります — タイトルがない場合は v{version} です。そのエントリ自身のページへリンクするため、リリースはタイムライン上の 1 行であると同時に共有可能なパーマリンクにもなります。
• category は日付の隣にタグとしてレンダリングされます。
• 下書きと sidebar.hidden のエントリはスキップされます。

このページは /changelog ルートが他に占有されていない場合にのみ表示されます。独自のデザインに置き換えるには、pages/changelog.astro にカスタムページを追加してください — それが優先され、Blume はデフォルトのタイムラインの生成を停止します。

このページは執筆されたものではなく生成されたものであるため、コンテンツツリーの一部ではありません — したがって /changelog を指すヘッダーのタブは、代わりに最新のエントリに解決されます。インデックス自体に遷移させるには、タブに href を指定してください:

navigation: {
  tabs: [
    { label: "Changelog", path: "/changelog", href: "/changelog" },
  ],
}

メジャーバージョンごとのグループ化

バージョンが semver に従っていて複数のメジャーにまたがる場合、Blume はタイムラインをメジャーバージョンごとにページ分割します。最新のメジャー系列のみが表示され、下部の Show N.x releases ボタンで、1 クリックごとに次に古いメジャーが表示されます:

• 検出は自動です — 設定は不要です。リストされたすべてのリリースが major.minor.patch としてパースでき、かつメジャーが複数ある場合にのみ有効になります。それ以外の場合、タイムラインはフラットのままです。
• モノレポが公開するスコープ付きタグにも対応しているため、pkg@2.0.0 は 2.x に、pkg@1.4.0 は 1.x にグループ化されます。
• これはプログレッシブエンハンスメントです: すべてのリリースはページの HTML(および RSS フィードと検索インデックス)に含まれたままなので、JavaScript のない読者 — およびクローラー — は完全な履歴を見ることができます。ボタンは、ページがハイドレートされた後にのみ古いメジャーを折りたたみます。

GitHub Releases から

エントリを手作業で書く代わりに、組み込みの github-releases ソースをリポジトリに向ければ、すべてのリリースが type: changelog エントリになります — 同じタイムラインとフィードが、すでに公開しているリリースから直接供給されます。Blume 自身の変更履歴もこの方法で構築されています:

content: {
  sources: [
    { type: "filesystem", root: "content" },
    {
      type: "github-releases",
      prefix: "changelog",
      owner: "acme",
      repo: "sdk",
    },
  ],
}

リリース名がタイトルになり、そのタグが changelog.version になり、公開日でタイムラインがソートされます。各リリースページには、そのノートから要約された固有のメタディスクリプションも付与されます — マークダウンを除去し、セクション見出しと changeset のコミットハッシュ接頭辞を削除し、blume audit がチェックする検索スニペットの長さに切り詰めたもので、サイトの説明にフォールバックすることはありません。プライベートリポジトリは GITHUB_TOKEN 環境変数で認証します。すべてのオプションについてはコンテンツソースを参照してください。

RSS フィード

Blume は /changelog/rss.xml に変更履歴フィードも構築し、date の新しい順にソートします。フィードには絶対的なサイト URL が必要なので、deployment.site を設定してください。その後 Blume がすべてのページに <link rel="alternate"> タグを挿入し、読者が自動的に見つけられるようにします。

フィードはデフォルトで有効です。seo.rss で調整できます:

seo: {
  rss: {
    enabled: true,
    types: ["blog", "changelog"],
    limit: 50,
  },
}

タイムラインを維持したままフィードだけをスキップするには、rss.types から "changelog" を削除してください。

構造化データ

構造化データが有効な場合、各変更履歴エントリは説明と公開日を伴う schema.org の TechArticle として出力されるため、検索エンジンがリリースを日付付きの記事としてインデックスできます。