Prepare for release, 2.7.0. (#799)

* Prepare for release, 2.7.0.

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

* Remove references to Jenkins.

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

* Update compatibility matrix.

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

---------

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

.github/workflows/unified-release.yml

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

CHANGELOG.md

@@ -1,7 +1,7 @@
 # CHANGELOG
 Inspired from [Keep a Changelog](https://keepachangelog.com/en/1.0.0/)
 
-## [Unreleased]
+## [2.7.0]
 ### Added
 - Added support for the `multi_terms` bucket aggregation ([#797](https://github.com/opensearch-project/opensearch-py/pull/797))
 ### Changed

COMPATIBILITY.md

@@ -9,7 +9,7 @@ The below matrix shows the compatibility of the [`opensearch-py`](https://pypi.o
 | --- | --- | --- |
 | 1.0.0 | 1.0.0-1.2.4 | |
 | 1.1.0 | 1.3.0-1.3.7 | |
-| 2.x.x | 1.0.0-2.14.0 | client works against OpenSearch 1.x as long as features removed in 2.0 are not used |
+| 2.x.x | 1.0.0-2.16.0 | client works against OpenSearch 1.x as long as features removed in 2.0 are not used |
 
 ## Upgrading
 

RELEASING.md

@@ -33,8 +33,8 @@ 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. Create a tag, e.g. v2.1.0, and push it to the GitHub repo.
-1. The [release-drafter.yml](.github/workflows/release-drafter.yml) will be automatically kicked off and a draft release will be created.
-1. This draft release triggers the [jenkins release workflow](https://build.ci.opensearch.org/job/opensearch-py-release/) as a result of which opensearch-py client is released on [PyPi](https://pypi.org/project/opensearch-py/).
-1. Once the above release workflow is successful, the drafted release on GitHub is published automatically.
-1. Add an "Unreleased" section to CHANGELOG, and increment version to the next patch release, e.g. v2.1.1. See [example](https://github.com/opensearch-project/opensearch-py/pull/593).
+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.
+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).

opensearchpy/_version.py

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

test_opensearchpy/run_tests.py

@@ -163,7 +163,7 @@ def run_all(argv: Any = None) -> None:
                 "test_opensearchpy/test_async/test_server_secured/",
             ]
 
-            # Jenkins/Github actions, only run server tests
+            # GitHub Actions, only run server tests
             if environ.get("TEST_TYPE") == "server":
                 test_dir = abspath(dirname(__file__))
                 if secured: