| 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.
For this reason it is also excluded from Prettier (see .prettierignore), whose
prose wrapping would otherwise reflow the entries.
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
Release metadata lines
The - Commit:, - Diff: and - Pinned JETLS: lines directly under a section
header are maintained by
scripts/prepare-release.sh. Do not edit
or add them by hand.
Entry style
- Start Added entries with "Added ..." and Fixed entries with "Fixed ...".
- Changed entries typically start with the component name.
- When closing a GitHub issue, append
(Closed <issue URL>) using the absolute
URL of the tracker where the issue lives: this repository for
extension-specific issues (e.g.
https://github.com/aviatesk/jetls-vscode/issues/NNN), or JETLS.jl for
language-feature issues observed through this extension (e.g.
https://github.com/aviatesk/JETLS.jl/issues/NNN).
- Use backticks for setting names, command 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 (module structure, VSCode API specifics,
process-management details) 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.
