| name | changelog |
| description | Invoke before committing user-facing JET changes such as features, bug fixes, compatibility changes, or deprecations. Skip internal refactors, CI or docs-only changes, and routine dependency bumps without user impact. |
Updating CHANGELOG.md
Format
This project follows Keep a Changelog.
Section structure
Add new entries under ## [Unreleased]. Do not edit a released section unless
the user explicitly requests it.
Use the established Keep a Changelog subsections as appropriate:
### Added for new functionality### Changed for changes to existing functionality or compatibility### Deprecated for features that will be removed### Removed for removed functionality### Fixed for bug fixes
Use ### Internal only when maintainers intentionally want to record a notable
internal change. Do not add empty subsections or introduce a new category when
an existing one fits.
Entry style
- Start Added entries with "Added ..." and Fixed entries with "Fixed ...".
- Describe Changed entries in terms of concrete behavior or compatibility.
- Refer to GitHub issues as
aviatesk/JET.jl#NNN.
- Use backticks for report types, function names, configuration names, and
other code elements.
- Record dependency changes when they affect supported Julia versions,
compatibility, installation, or user-visible behavior. Omit routine bumps.
Entry content
Write entries from the user's perspective. Describe what changed in terms of
user-visible behavior, not implementation details.
- Do not include lowered IR details, Compiler.jl hook methods, abstract
interpretation state, or virtual-process internals unless users can
reasonably observe or interact with them.
- The "why" of a fix rarely matters to users; the "what" does. If the prior
behavior is worth mentioning, describe its user-visible symptom rather than
its internal cause.
