Preparing for next developer iteration, 2.7.1. (#802)

Signed-off-by: dblock <[email protected]>

.github/workflows/unified-release.yml

@@ -9,7 +9,7 @@ jobs:
     strategy:
       fail-fast: false
       matrix:
-        stack_version: ["2.7.0"]
+        stack_version: ["2.7.1"]
 
     steps:
       - name: Checkout

CHANGELOG.md

@@ -1,6 +1,14 @@
 # CHANGELOG
 Inspired from [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
+## [Unreleased]
+### Added
+### Changed
+### Deprecated
+### Removed
+### Fixed
+### Security
+
 ## [2.7.0]
 ### Added
 - Added support for the `multi_terms` bucket aggregation ([#797](https://github.com/opensearch-project/opensearch-py/pull/797))
@@ -276,6 +284,7 @@ Inspired from [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 ### Security
 
 [Unreleased]: https://github.com/opensearch-project/opensearch-py/compare/v2.6.0...HEAD
+[2.7.0]: https://github.com/opensearch-project/opensearch-py/compare/v2.6.0...v2.7.0
 [2.6.0]: https://github.com/opensearch-project/opensearch-py/compare/v2.5.0...v2.6.0
 [2.5.0]: https://github.com/opensearch-project/opensearch-py/compare/v2.4.2...v2.5.0
 [2.4.2]: https://github.com/opensearch-project/opensearch-py/compare/v2.4.0...v2.4.2

RELEASING.md

@@ -34,7 +34,7 @@ Repositories create consistent release labels, such as `v1.0.0`, `v1.1.0` and `v
 The release process is standard across repositories in this org and is run by a release manager volunteering from amongst [maintainers](MAINTAINERS.md).
 
 1. Update the version in [CHANGELOG](CHANGELOG.md), [_version.py](opensearchpy/_version.py) and [unified-release.yml](.github/workflows/unified-release.yml), make a pull request and have it merged. See [example](https://github.com/opensearch-project/opensearch-py/pull/799).
-2. Create a tag, e.g. v2.1.0, and push it to the GitHub repo.
-3. The [release-drafter#draft-a-release](.github/workflows/release-drafter.yml) workflow will be automatically kicked off and a draft release will be created.
+2. Check out the [upstream repo](https://github.com/opensearch-project/opensearch-py), make sure it's up-to-date with `git pull origin main`, create a tag, e.g. `git tag v2.1.0`, and push it to GitHub with `git push origin --tags`.
+3. The [release-drafter#draft-a-release](.github/workflows/release-drafter.yml) workflow will be automatically kicked off and a draft release will be created along with a release issue that requires approval from another maintainer. See [example](https://github.com/opensearch-project/opensearch-py/issues/801).
 4. The [release-drafter#pypi-publish](.github/workflows/release-drafter.yml) workflow will publish the release to [PyPi](https://pypi.org/project/opensearch-py/).
-5. Add an "Unreleased" section to [CHANGELOG](CHANGELOG.md), update the [COMPATIBILITY](COMPATIBILITY.md) matrix, and increment version in [_version.py](opensearchpy/_version.py) to the next patch release, e.g. v2.1.1. See [example](https://github.com/opensearch-project/opensearch-py/pull/593).
+5. Add an "Unreleased" section to [CHANGELOG](CHANGELOG.md), update the [COMPATIBILITY](COMPATIBILITY.md) matrix, and increment version in [_version.py](opensearchpy/_version.py) to the next patch release, e.g. v2.1.1. See [example](https://github.com/opensearch-project/opensearch-py/pull/802).

opensearchpy/_version.py

@@ -24,4 +24,4 @@
 #  specific language governing permissions and limitations
 #  under the License.
 
-__versionstr__: str = "2.7.0"
+__versionstr__: str = "2.7.1"