Changelogs
Product-specific public release history beginning with each agreed public v1 release.
Changelogs are separated by product so users can follow only the software they actually run.
Release-history rule
Public changelogs begin with the agreed v1 release of each product. Pre-v1 work remains internal and is not backfilled into the public history.
What belongs in a changelog
Record user-visible features, behaviour changes, important fixes, compatibility changes and any update action the user needs to take. Avoid internal engineering notes and proprietary implementation detail.