changelog

name	changelog
description	Invoke before committing user-facing changes (new features, bug fixes, behavior changes) to update CHANGELOG.md. Skip for internal refactors, CI, docs-only, or minor dependency bumps.

Updating CHANGELOG.md

Format

This project follows Keep a Changelog.

Line length

CHANGELOG.md is exempt from the 80-character Markdown line length rule because it is used for GitHub release notes, where hard line breaks disrupt rendering.

That said, do not put everything on a single line unconditionally. Break lines at natural points (sentence boundaries, after colons, etc.) when an entry is long enough to benefit from it. Short, single-sentence entries are fine as one line.

Section structure

New entries go under the ## Unreleased section. Use the following subsections as needed (in this order):

• ### Announcement -- important notices (always first if present)
• ### Added -- new features
• ### Changed -- changes to existing functionality
• ### Fixed -- bug fixes

Entry style

• Start Added entries with "Added ..." and Fixed entries with "Fixed ...".
• Changed entries typically start with the component name (e.g. "lowering/undef-local-var now ...").
• When closing a GitHub issue, append (Closed https://github.com/aviatesk/JETLS.jl/issues/NNN).
• Use backticks for diagnostic names, function names, and code elements.

Entry content

Write entries from the user's perspective. Describe what changed in terms of user-visible behavior — not implementation details.

• Don't include internal mechanisms (AST node types, specific JuliaLowering/JuliaSyntax internals, traversal strategies) unless a user could reasonably observe or interact with them.
• The "why" of a fix rarely matters to users; the "what" of the new behavior does. If the prior behavior is worth mentioning, describe its user-visible symptom, not its cause.