Add release notes drafter for OpenSearch

[saratvemulapalli]

Is your feature request related to a problem? Please describe.
Add release notes drafter for OpenSearch which compiles all the commits made into a release.

Describe the solution you'd like
Github actions support this via https://github.com/release-drafter/release-drafter.

[abbashus]

Does this Github action have the provision to separate out the commits into different sections like Feature, Bugs, Enhancement, Documentation etc? I would like to have something like this https://github.com/opendistro-for-elasticsearch/sql/releases/tag/v1.13.0.0

[saratvemulapalli]

Does this Github action have the provision to separate out the commits into different sections like Feature, Bugs, Enhancement, Documentation etc? I would like to have something like this https://github.com/opendistro-for-elasticsearch/sql/releases/tag/v1.13.0.0

Yes it does. It depends on how we label them, and for our project looks like we are diligently labeling them which should take care of that.
It would be very similar to the plugin release notes.

[saratvemulapalli]

Looks like the release drafter doesn't support multiple release branches i.e we cannot have different release notes for each of the release branch.
Ref: release-drafter/release-drafter#844

[saratvemulapalli]

Created notes for RC1 using https://github.com/ariatemplates/git-release-notes.
It doesnt automate the drafter, doesn't categorize labels but atleast an easier way to generate them once per release.
We can continue to scout for better solutions.

[saratvemulapalli]

Posting comments from the PR to here:

"I would ideally love something like:
Category:
PR title (#number)
PR description
Authored by abc@

Lets work on this for the next release. As we have discussed we have to diligent in our back port PRs so that authors are given the credit."

[tmarkley]

Have we considered creating a changelog as well? As a customer of other repositories, changelogs are so much easier to parse/search when dealing with version bumps/upgrades than individual release notes. Having a full summary of breaking changes, new features, etc. between all previous versions is incredibly useful.

We could use something like this to aid in the generation: https://github.com/github-changelog-generator/github-changelog-generator

A great example is mocha, where they include the version number, date, sections in each release, and emojis (a fun bonus feature): https://github.com/mochajs/mocha/blob/master/CHANGELOG.md

[saratvemulapalli]

Have we considered creating a changelog as well? As a maintainer of other repositories, changelogs are so much easier to parse/search when dealing with version bumps/upgrades than individual release notes. Having a full summary of breaking changes, new features, etc. between all previous versions is incredibly useful.

We could use something like this to aid in the generation: https://github.com/github-changelog-generator/github-changelog-generator

This is nice!

[nknize]

Is this a meta issue? Is it done? Can this be closed? Or is there a backport needed somewhere?

[Rishikesh1159]

Just wanted to document how I generated 2.1.0 release notes, so that this process might help in automation or for next release.
Steps:

* `git checkout origin/2.1`
* `git log --pretty=format:"* %s" --since=3-23-2022 > release-notes/opensearch.release-notes-2.1.0.md`
* Manually organize file sections
  * Add Date / Version section (copy + modify from previous release)
  * Enhancements/Bug fixes/Maintenance
* Replace pull request ids with full urls via regex
  * Find: `\(#(\d+)\)$`
  * Replace: `([#$1]([https://github.com/opensearch-project/opensearch/pull/$1))`](https://github.com/opensearch-project/opensearch/pull/$1))%60)
* Commit with these steps / modified with additional details

-> In second line of above command block, when using --since the date should be selected carefully. You should select the date when opensearch version bumped from MajorVersion.x to new version, example (2.x version bump to 2.1)

-> I had to manually go through each commit and sort it out to one of the sections mentioned here.

-> Next I had to check which commits are already present in previous release version notes and remove them from current release notes manually. This step can be done before sorting out each commit to appropriate section.

->Make sure no breaking changes are included if it is a minor release versions.