Internal release notes:

* consisting of PRs merged since last release. (This is better than manually updating CHANGELOG. Do not allow direct commits to main w/o a PR.)

* internal audience is engineering, PMs, customer success & support, these do not leave the company.

* PRs can be examined for more context if needed. This is a good enough balance between noise & automation.

* If you use a working tracking system like JIRA or GitHub issues, join the PRs w/ the system to output priority and other labels (like Feature/Bug). This will help internal stakeholders quickly identify how important each line is. Sort by priority and/or group by labels.

External release notes:

* manually updated log of important changes, such as new features or other larger changes. These do not include all bug fixes.

* visible to customers.

* do not mention version numbers, only dates. You do not want to leak how often you release, or customers will start demanding release notes per version or dictating your release schedule.

When you fix bugs for customers, tell them what day/time the bug fix went live.

Obtaining set of PRs merged since last release is non-trivial, but doable.