The Changelog Format Is Now Standardized

SGEN's changelog now ships with a single repeatable shape for every release entry. One format, consistently applied, so readers always know what changed, which surface it touched, and what the update means for them.

What changed

In a fragmented stack, change-tracking is a black box — release notes scattered across plugin authors, readers left guessing what actually shipped. SGEN's standardized changelog ships audit-ready, with one repeatable shape per release.

The changelog format is now standardized so future release entries can be tracked in a more consistent way across the docs site. Each entry declares a surface tag, a type (Update, New, Fix), and a plain-language summary — no guesswork about what area was affected or whether an entry matters to you.

Structure
One shape per entry

Every release entry uses the same fields: surface tag, type, and summary. The structure is consistent across all entries, making it straightforward to scan and reference.

Clarity
What changed and where

Each entry names the surface it touches and the type of change. Readers know immediately whether an entry is relevant to them — no hunting through unstructured notes.

Where it fits

Changelog quality depends on repeatable structure. A stable format makes it easier to explain what changed, which surface was affected, and what readers should understand from the update. This matters because it turns the changelog from a release artifact into a reliable reference.

For launch, this is a foundational item. The visible changelog set is still growing — each new entry will follow this format as the catalog builds out.

Surface tag

Identifies which area of the product the change touches — for example, changelog, builder, media, or admin. Lets readers filter for what matters to them.

Type

Labels the nature of the change: Update, New, or Fix. Sets the right expectation before a reader opens the entry.

Summary

A plain-language sentence describing what was released and why it matters. Written for the reader, not the developer.

Heads up No setup needed. The standardized format applies to all new changelog entries going forward. Existing entries on the docs site already follow this shape.

What to do next