Skip to main content

​
How we build the changelog

This document describes how the changelog is produced so future editors can maintain or extend it. Audience: Developers and solution architects building with our product. Focus on “what changed that I can use or must adapt to.” Structure: Three changelog files — changelog/2024.mdx, changelog/2025.mdx, changelog/2026.mdx. Within each file, one section per month (e.g. ## March 2026). You can skip a month if there is nothing to report. Line is one product area (section within a month), not a separate changelog. Most important: Account for all changes. Use repo activity and #changelog so nothing shipped is missing.

​
Process

  1. Ongoing — When a team ships something user-facing (new feature, API change, Line SDK release, model/voice update), post a short summary (even one sentence) to the internal #changelog channel at ship time. In product PRs, fill the “Changelog” line in the template if the PR is user-facing.
  2. End of month — See what shipped — So the changelog reflects reality and isn’t sparse: use #changelog and repo activity (e.g. git log, PR list) for product, bifrost, and docs to see what shipped. Cross-check the Reference: key dates and versions section below for API versions, model snapshots, and Line releases so items land in the correct month.
  3. Draft — Add the new month to the correct year file (e.g. April 2026 → edit changelog/2026.mdx). For each month include:
    • Overview — One short paragraph summarizing what changed that month.
    • Sections by product area — Use the section list below. Turn repo activity and #changelog bullets into clear, end-user-focused bullets; link to docs where they exist. Omit empty sections.
    • Line — For Line SDK releases, you can put content from Line release notes into the appropriate month/date in the changelog; don’t change that content when placing it. AI-assisted option: If you have commit or merge data for the month, use the prompts in _cursor-prompts.md (Phase 1: classify → Phase 2: map to sections → Phase 3: output). Paste the result into the correct year file under the new month. Always review and cross-check the Reference section below before publish.
  4. Review — Have a reviewer (e.g. TL or Chris Hughes) confirm accuracy and tone. Resolve any <!-- Reviewer: ... --> or [Reviewer note: ...] comments.
  5. Publish — The Changelog tab in docs.json already lists changelog/2026, changelog/2025, changelog/2024. No per-month pages to add; just ensure the year file is saved with the new month.

​
Format (standardize across all changelog pages)

Use the same structure and formatting in 2024.mdx, 2025.mdx, and 2026.mdx so the changelog is scannable and consistent. We use Mintlify Update components for each month; each label appears in the right-hand table of contents and supports RSS at /changelog/YYYY/rss.xml. One block per month
  • Use <Update label="Month YYYY"> (e.g. <Update label="March 2024">). Use full month name. Optional: add description="v1.2.3" or a short tag if useful.
  • Order: newest month first (December before November, etc.) within each year file.
  • Close with </Update>. No --- between Updates.
Feature-first content inside each Update
  • Start each item with Bold feature or area name (e.g. API, Voice Conversion endpoint, Line SDK v0.2) followed by an em dash and 1–2 sentences.
  • One paragraph per logical change or product area. Prefer multiple short paragraphs over one long run-on. Break up long bullets into two or three sentences (or a short list) so entries are easy to scan.
  • Use bold for feature names, major endpoints, and models. Use backticks for code, model IDs, endpoint paths, and params (e.g. sonic-3-latest, /voices/create, voice_id).
  • Links: [link text](/path) for doc links. For external URLs use [text](url).
  • Skip generic catch-alls like “Minor bug fixes and improvements”; only list concrete changes.
Breaking / Deprecated
  • Lead with Breaking: or Breaking: model/version then a short sentence and migration note. Use a list when listing removed items (Embeddings, stability cloning, etc.). Link to migration docs where they exist.
Line / release notes
  • Summarize Line SDK (or other product) releases in 2–4 short paragraphs with bold feature names. Then add: “For full details, migration guide, breaking changes, and code samples, see Line release notes.” Do not embed the full release-notes content in the changelog.
RSS
  • Add rss: true to the frontmatter of each year page so subscribers get an RSS feed at .../changelog/2026/rss.xml (and 2025, 2024).
External-only / style
  • Do not use internal repo or service names (e.g. Bifrost, Gypsum, Inferno, Modal, Rodin, KEDA). Rephrase to user-facing wording or drop.
  • Do not mention internal ticket IDs (PRO-, BIF-, CAR-, etc.); describe the change in plain language (e.g. “audio improved pipeline”, “concurrency fixes”).
  • Do not mention customers, partners, booths, or talks. Focus on user-visible changes and clear benefits (e.g. model aliasing, user_id → owner_id, concurrency fixes) without over-sharing internals.
  • Refactors and internal-only changes are not for external docs unless they have a clear user benefit.

​
Section list (use every month, omit if empty)

Within each month, use these sections in order so developers and solution architects know where to look. Line is one of the product areas.

​
Reference: key dates and versions

Use these when assigning events to the correct month. Sourced from versioned docs, changelog, and Line release notes. API / docs versions TTS / model snapshots Line / Agents Planned deprecation

​
Artifacts in this folder

  • _cursor-prompts.md — Phase 1–4 prompts for Cursor: classify commits by impact, map to sections, output MDX, optional strategic layer. Use when you have commit or merge data (e.g. from git log or PR list).
  • _process.md — This file.

​
Style

  • Include: new features, new endpoints or SDK versions, new models/voices, deprecations/removals, major UI/product changes.
  • Exclude (or one line): internal refactors, infra-only changes, minor bug fixes unless user-facing.
  • Unclear cases: add <!-- Reviewer: ... --> so reviewers can include, drop, or rephrase.