Create releases notes tracking tag and template

[ni]

Create releases notes tracking tag and template

[astarche]

Release notes generation is explained on this page with an example config yaml.

The primary goal is to make it easy-to-remember/hard-to-forget. Ideally it should be well-organized and not require manual edits, but that's nice-to-have.

Proposal:

• Add a breaking-change tag for any proto changes.
• Add a release-notes tag for any other changes to include in the release notes.

We typically introduce breaking changes as part of a codegen change, sometimes the PR title will not be the best description of the break.

To mitigate this we should:

1. Isolate the codegen change from addition of new APIs/features.
2. Reword the title to emphasize the API change as much as reasonably possible (but don't force it).
3. Add a "Breaking Change" section to the PR description describing the specific break.
4. Reword the generated release notes as necessary.

Thoughts @reckenro @gregstoll @harsha-bhushan ?

[gregstoll]

1 sounds like kind of a pain in some cases. I think I'd lean towards 3 or 4. 4 sounds optimal if there aren't too many of these breaking changes. (which hopefully there won't be!)

[astarche]

Yeah, true. I'd say "Isolate the codegen change from addition of new APIs/features" is preferred in general and a stronger preference in this case. But, we override that preference pretty frequently for pragmatism's sake. That's fine. A softer guidance could be "think about if this change should be in release notes and, if so, what can you do to make this PR a better reference link?".

[harsha-bhushan]

Yes, we shouldn't be breaking a lot of code.
Currently in the early adoption stage of the product & frequent releases, it's better to review & include only what is worth calling out in the release notes. And avoid cluttering the release notes & confusing especially the new users. We could add some other custom tag for such PRs, so that they are not automatically picked up while creating a release, but it would aid us update the notes.

But eventually, once we are done with all driver support & the community starts to contribute to this repo, we could have a more stricter guidance.

[astarche]

I went ahead and added a breaking-change tag and tagged the appropriate PRs. I'll figure out how to handle that when adding release notes.