[Backport 2.x] Create separate file for unreleased 3.0 changes (#13040)…

… (#13140)

* Create separate file for unreleased 3.0 changes (#13040)

Contributors and maintainers frequently put changelog entries in the
wrong section. It's an easy mistake to make! Given that making changes
intended for the next minor release is the norm, this change optimizes
that process by making `CHANGELOG.md` contain _only_ entries for the
next minor. Truly breaking changes intended for the next major are kept
in a separate file. Credit to @msfroh for the idea.

Signed-off-by: Andrew Ross <andrross@amazon.com>
Signed-off-by: Kunal Kotwani <kkotwani@amazon.com>
Co-authored-by: Kunal Kotwani <kkotwani@amazon.com>

* Update changes as per 2.x

Signed-off-by: Kunal Kotwani <kkotwani@amazon.com>

---------

Signed-off-by: Andrew Ross <andrross@amazon.com>
Signed-off-by: Kunal Kotwani <kkotwani@amazon.com>
Co-authored-by: Andrew Ross <andrross@amazon.com>

.github/workflows/changelog_verifier.yml

@@ -1,7 +1,7 @@
 name: "Changelog Verifier"
 on:
  pull_request:
- types: [opened, edited, review_requested, synchronize, reopened, ready_for_review, labeled, unlabeled]
+ types: [opened, synchronize, reopened, ready_for_review, labeled, unlabeled]
 
 jobs:
  # Enforces the update of a changelog file on every pull request
@@ -13,7 +13,8 @@ jobs:
  with:
  token: ${{ secrets.GITHUB_TOKEN }}
  ref: ${{ github.event.pull_request.head.sha }}
-
  - uses: dangoslen/changelog-enforcer@v3
+ id: verify-changelog
  with:
  skipLabels: "autocut, skip-changelog"
+ changeLogPath: 'CHANGELOG.md'

CONTRIBUTING.md

@@ -146,12 +146,12 @@ Adding in the change is two step process:
 2. Update the entry for your change in [`CHANGELOG.md`](CHANGELOG.md) and make sure that you reference the pull request there.
 
 ### Where should I put my CHANGELOG entry?
-Please review the [branching strategy](https://github.com/opensearch-project/.github/blob/main/RELEASING.md#opensearch-branching) document. The changelog on the `main` branch will contain sections for the _next major_ and _next minor_ releases. Your entry should go into the section it is intended to be released in. In practice, most changes to `main` will be backported to the next minor release so most entries will likely be in that section.
+Please review the [branching strategy](https://github.com/opensearch-project/.github/blob/main/RELEASING.md#opensearch-branching) document. The changelog on the `main` branch will contain **two files**: `CHANGELOG.md` which corresponds to unreleased changes intended for the _next minor_ release and `CHANGELOG-3.0.md` which correspond to unreleased changes intended for the _next major_ release. Your entry should go into file corresponding to the version it is intended to be released in. In practice, most changes to `main` will be backported to the next minor release so most entries will be in the `CHANGELOG.md` file.
 
 The following examples assume the _next major_ release on main is 3.0, then _next minor_ release is 2.5, and the _current_ release is 2.4.
 
-- **Add a new feature to release in next minor:** Add a changelog entry to `[Unreleased 2.x]` on main, then backport to 2.x (including the changelog entry).
-- **Introduce a breaking API change to release in next major:** Add a changelog entry to `[Unreleased 3.0]` on main, do not backport.
+- **Add a new feature to release in next minor:** Add a changelog entry to `[Unreleased 2.x]` in CHANGELOG.md on main, then backport to 2.x (including the changelog entry).
+- **Introduce a breaking API change to release in next major:** Add a changelog entry to `[Unreleased 3.0]` to CHANGELOG-3.0.md on main, do not backport.
 - **Upgrade a dependency to fix a CVE:** Add a changelog entry to `[Unreleased 2.x]` on main, then backport to 2.x (including the changelog entry), then backport to 2.4 and ensure the changelog entry is added to `[Unreleased 2.4.1]`.
 
 ## Review Process