It would be great if as part of the pull requests themselves we can add in a common file what all deprecations or breaking changes are happening. Creating release notes from commits is ok. But as people are running datahub in production people would need to know if there are any deprecations/breaking changes/config changes/new configs. This will become a serious concern if people actually start using datahub heavily. Everyone who is running datahub in production will have to try to go over all commits to find out if something is a breaking change. Apache superset does this. They have a CHANGELOG https://github.com/apache/superset/blob/master/CHANGELOG.md which is generated via commits and another UPDATING.MD file which contains these breaking changes https://github.com/apache/superset/blob/master/UPDATING.md. This UPDATING file is updated in every PR that has a breaking change. It is part of their process. During release all of those can optionally be added to the release notes. It would be great if datahub can adopt a similar process. Otherwise updating datahub will introduce risk whenever we want to do an update in production.

Great suggestion @square-activity-64562. I have been populating a “Notable Changes” section in release notes recently, but adding something small for big PRs to document their impact will scale better. We’ll start piloting something like this.