Changelog
Purpose
The purpose of a changelog is to log or record notable changes.
Tone
instructional, straightforward
content_type
changelog
Ownership
Developers and engineers maintain changelogs manually or via an automated process that their team owns. PCX provides a review but should not own creating or writing changelogs.
The structure of the page can differ depending on the frequency or type of page.
Structure (single-page)
When creating a changelog, you need a Markdown page file and a corresponding YAML file in the
/data/changelogs
folder.
The combination of these files allows us to:
- Render traditional changelog content on an HTML page.
- Programmatically create an RSS feed with the changelog content.
- Pull all our changelog content into a Cloudflare-wide changelog.
Markdown file
Your Markdown file needs to have several special values to pull in the changelog information. These values are highlighted in the sample page.
YAML file
The product-changelog
component renders data that lives in a file within the
/data/changelogs
folder.
-
link
string
- Relative path to the changelog page, such as
"/queues/changelog/"
.
- Relative path to the changelog page, such as
-
productName
string
- Product name to display on the changelog product filter list, as well as other areas of the template.
-
productLink
string
- Link to top-level docs for your product (helpful for context if someone is landing on the top-level changelog page)
-
productArea
string
- Rollup grouping to surface related products together in context.
-
productAreaLink
string
- Rollup grouping to surface related products together in context. Helps pull together related RSS feeds.
-
entries
object
-
publish_date
date
- Date of published change, formatted as
YYYY-MM-DD
.
- Date of published change, formatted as
-
title
string
- Name of published change. Optional, but highly encouraged.
-
description
string
- Markdown string that also follows YAML conventions. For multi-line strings, start the entry with
|-
and then type on an indented new line.
- Markdown string that also follows YAML conventions. For multi-line strings, start the entry with
-
Structure (multi-page)
In some cases, your changelog may have a separate page for each entry. The general structure is the same as the single-page changelog, but with a few small differences.
Markdown files
Top-level pages
For the top-level pages, you need the same frontmatter as the single-page example, but do not include any shortcodes in the body of the page.
Individual entries
For each entry page, create a regular markdown page. These do not require a separate style of page or any adjustments.
YAML file
Each individual entry needs an abbreviated entry in the changelog .yaml
file.
-
publish_date
date
- Date when the page was published, formatted as
YYYY-MM-DD
. For pages with scheduled changes, you should update this field when adding/updating entries, so that the changelog item gets placed at the top of the changelog list (and feed). You should not update this date when clearing all scheduled changes due to a release, since this change is not as relevant.
- Date when the page was published, formatted as
-
individual_page
boolean
- Used to pull in the content from the page itself, as opposed to structured data in YAML.
-
link
string
- Link to the individual page.
-
scheduled
boolean
- Should be included for scheduled pages. Because this component renders content on the underlying page, you should only have a) one scheduled entry per scheduled entry page and b) only a scheduled entry when the scheduled entry page has content.
-
scheduled_date
date
- Should be included for pages with scheduled changes. Helps render the date of the upcoming change in the title, which provides more actionable information to folks scanning titles or the associated RSS feeds.